课程介绍课程来自于尚硅谷Docker与微服务实战（2022版）Docker是一个开源的应用容器引擎，让开发者可以打包他们的应用以及依赖包到一个可移植的镜像中，然后发布到任何流行的Liux或Widow操作系统的机器上，也可以实现虚拟化。容器是完全使用沙箱机制，相互之间不会有任何接口。Docker是PaaS提供商dotCloud开源的一个基于LXC的高级容器引擎，源代码托管在Githu上,基于go语言并遵从Aache2.0协议开源。Docker自2013年以来非常火热，无论是从githu上的代码活跃度，还是Redhat在RHEL6.5中集成对Docker的支持,就连Google的ComuteEgie也支持docker在其之上运行。一款开源软件能否在商业上成功，很大程度上依赖三件事-成功的uercae(用例),活跃的社区和一个好故事。dotCloud之家的PaaS产品建立在docker之上，长期维护且有大量的用户，社区也十分活跃，接下来我们看看docker的故事。环境管理复杂-从各种OS到各种中间件到各种a,一款产品能够成功作为开发者需要关心的东西太多，且难于管理，这个问题几乎在所有现代IT相关行业都需要面对。云计算时代的到来-AWS的成功,引导开发者将应用转移到cloud上,解决了硬件管理的问题，然而中间件相关的问题依然存在(所以oetackHEAT和AWScloudformatio都着力解决这个问题)。开发者思路变化提供了可能性。虚拟化手段的变化-cloud时代采用标配硬件来降低成本，采用虚拟化手段来满足用户按需使用的需求以及保证可用性和隔离性。然而无论是KVM还是Xe在docker看来,都在浪费资源，因为用户需要的是高效运行环境而非OS,GuetOS既浪费资源又难于管理,更加轻量级的LXC更加灵活和快速LXC的移动性-LXC在liux2.6的kerel里就已经存在了，但是其设计之初并非为云计算考虑的，缺少标准化的描述手段和容器的可迁移性，决定其构建出的环境难于迁移和标准化管理(相对于KVM之类image和ahot的概念)。docker就在这个问题上做出实质性的革新。这是docker最独特的地方。VM技术和容器技术对比面对上述几个问题，docker设想是交付运行环境如同海运，OS如同一个货轮，每一个在OS基础上的软件都如同一个集装箱，用户可以通过标准化手段自由组装运行环境，同时集装箱的内容可以由用户自定义，也可以由专业人员制造。这样，交付一个软件，就是一系列标准化组件的集合的交付，如同乐高积木，用户只需要选择合适的积木组合，并且在最顶端署上自己的名字(最后一个标准化组件是用户的a)。这也就是基于docker的PaaS产品的原型。微服务是一种开发软件的架构和组织方法，其中软件由通过明确定义的API进行通信的小型独立服务组成。这些服务由各个小型独立团队负责。微服务架构使应用程序更易于扩展和更快地开发，从而加速创新并缩短新功能的上市时间。整体式架构与微服务架构通过整体式架构，所有进程紧密耦合，并可作为单项服务运行。这意味着，如果应用程序的一个进程遇到需求峰值，则必须扩展整个架构。随着代码库的增长，添加或改进整体式应用程序的功能变得更加复杂。这种复杂性限制了试验的可行性，并使实施新概念变得困难。整体式架构增加了应用程序可用性的风险，因为许多依赖且紧密耦合的进程会扩大单个进程故障的影响。使用微服务架构，将应用程序构建为独立的组件，并将每个应用程序进程作为一项服务运行。这些服务使用轻量级API通过明确定义的接口进行通信。这些服务是围绕业务功能构建的，每项服务执行一项功能。由于它们是独立运行的，因此可以针对各项服务进行更新、部署和扩展，以满足对应用程序特定功能的需求。文件目录视频01_前言闲聊和课程说明.m402_docker为什么出现.m403_docker理念简介.m404_docker是什么.m405_传统虚拟机和容器的对比.m406_docker能干嘛解决什么问题.m407_docker官网介绍.m408_docker三要素.m409_docker平台入门图解.m410_docker平台架构图解.m411_ceto7上安装docker.m412_镜像加速器配置.m413_helloworld分析介绍3要素配合.m414_为什么Docker会比VM虚拟机快.m415_帮助启动类命令.m416_镜像命令.m417_uutu容器说明.m418_容器命令A.m419_容器命令B.m420_容器命令C.m421_容器命令D.m422_容器命令E.m423_镜像的分层概念.m424_commit命令上集.m425_commit命令下集.m426_本地镜像发布到阿里云.m427_docker私有库简介.m428_新镜像推送私服库案例.m429_容器数据卷是什么.m430_容器数据卷能干嘛.m431_容器卷和主机互通互联.m432_容器卷ro和rw读写规则.m433_容器卷之间的继承.m434_docker上安装常用软件说明.m435_tomcat安装上集.m436_tomcat安装下集.m437_myql安装上集.m438_myql安装下集.m439_redi常规安装.m440_高级篇简介.m441_myql主从复制docker版.m442_分布式存储之哈希取余算法.m443_分布式存储之一致性哈希算法.m444_分布式存储之哈希槽算法.m445_3主3从redi集群配置上集.m446_3主3从redi集群配置中集.m447_3主3从redi集群配置下集.m448_redi集群读写error说明.m449_redi集群读写路由增强正确案例.m450_查看集群信息clutercheck.m451_主从容错切换迁移.m452_主从扩容需求分析.m453_主从扩容案例演示.m454_主从缩容需求分析.m455_主从缩容案例演示.m456_分布式存储案例小总结.m457_Dockerfile简介.m458_DockerFile构建过程解析.m459_Dockerfile保留字简介.m460_ceto之dockerfile需求说明.m461_ceto之dockerfile案例演示.m462_虚悬镜像.m463_新建微服务工程并形成jar包.m464_dockerfile发布微服务部署到docker容器.m465_测试容器上的微服务.m466_dockeretwork简介.m467_dockeretwork常用命令.m468_dockeretwork能干嘛.m469_dockeretwork网络模式有几种.m470_dockeretwork底层i和容器映射变化.m471_dockeretwork之ridge.m472_dockeretwork之hot.m473_dockeretwork之oe.m474_dockeretwork之cotaier.m475_dockeretwork之自定义网络上集.m476_dockeretwork之自定义网络中集.m477_dockeretwork之自定义网络下集.m478_comoe是什么能干嘛.m479_comoe下载安装步骤.m480_comoe核心概念.m481_微服务改造升级并生成新镜像.m482_不用comoe编排服务上集.m483_不用comoe编排服务下集.m484_使用comoe编排服务上集.m485_使用comoe编排服务中集.m486_使用comoe编排服务下集.m487_Portaier简介和安装.m488_Portaier常规操作.m489_Portaier补充说明.m490_CIG容器重量级监控系统介绍.m491_CIG结合comoe一键搭建监控平台.m492_CIG三平台登陆验证通过.m493_CIG添加ael.m494_CIG配置监控业务规则.m495_终章の总结.m4脑图笔记.zi...

2023-01-07 微服务docker部署 微服务 docker k8s

课程介绍课程来自Docker系统介绍+进阶实践（2021最新版）（完）文件目录@Docker第一章Docker安装与介绍更多课程微信客服.jg更新描述.txtreadme.md文档.zi1-7在Liux系统上安装Docker.m41-5在Widow上安装Docker.m41-4Docker安装介绍.m41-1课程指南.m41-6Mac系统安装Docker.m41-2容器技术简介.m41-3课程文档及源代码.m4第2章容器入门readme.md文档.zi2-2了解docker命令行.m42-8widow如何运行dockeregie.m42-3图像和容器.m42-9容器和虚拟机.m42-5批处理操作命令行技巧.m42-7Cotaier的交互模式.m42-6cotaier.m4的附加和分离模式2-4创建我们的第一个cotaier.m42-10创建容器时幕后发生了什么.m42-1本章介绍.m4第3章图像创建、管理和发布readme.md3-5Dockerfile.m4简介3-6图像构建与分享.m43-8说说刮这个镜子.m43-1如何获取图片.m43-2镜像注册表介绍.m43-7通过commit.m4创建镜像3-4dockerimage.m4的导入导出3-3图像获取、查看和删除.m4第4章Dockerfile完整指南readme.md4-4文件复制和目录操作.m44-8一起构建PythoFlak镜像.m44-6容器启动命令CMD.m44-13章节概要.m44-7容器启动命令ENTRYPOINT.m44-5编译参数和环境变量.m44-2如何选择基础图片.m44-11Dockerfile技巧-多阶段uild.m44-3通过RUN.m4执行指令4-9Dockerfile技巧——cache.m4的合理使用4-10Dockerfile技巧-dockerigore.m44-1本章介绍.m44-12Dockerfile技巧-尝试使用非root用户.m4第5章Docker存储readme.md5-1本章介绍.m45-5BidMoutractice.m4的Docker开发环境5-6机器间共享数据.m45-3数据量练习MySQL.m45-2DataVolume.m4用于数据持久性5-4绑定Mout.m4实现数据持久化第6章Docker网络readme.md6-11端口转发和Dockerfile.m46-13Liux网络命令空间.m46-2NetworkBa​​ic.m4回顾6-7网络知识补充NAT.m46-6容器对外通信的桥接方式.m46-10Cotaier的端口转发.m46-1本章介绍.m46-8创建和使用自定义ridge(to).m46-4容器网络涉及哪些问题.m46-5容器间通信的桥接方式.m46-3常用网络命令.m46-9创建和使用自定义桥接（下）.m46-12主机网络详情.m4第7章Docker编写readme.md文档.zi7-9docker-comoe水平缩放和负载均衡.m47-12服务依赖和健康检查（第二部分）.m47-4docker-comoe命令行基本使用.m47-11服务依赖和健康检查（上）.m47-6docker-comoe服务更新.m47-2docker-comoe安装.m47-10docker-comoe环境变量.m47-3编写文件结构和verio.m47-13docker-comoe投票应用实践.m47-8docker-comoe网络（下）.m47-7docker-comoeetwork(o).m47-5docker-comoe镜像构建和ull.m47-1什么是docker-comoe.m4第8章Docker群readme.md文档.zi8-6Swarm初体验overlayetwork.m48-14warm使用本地volume.m48-2warm单节点快速入门.m48-3warm单节点服务初体验.m48-13在warm中使用ecret.m48-11部署多服务应用.m48-5warm三节点服务再体验.m48-7warm的覆盖网络detail.m48-12栈部署多服务应用.m48-1dockerwarm介绍.m48-9warm的入口网络详解（下）.m48-15群练习投票a.m48-8warm的入口网络详解（上）.m48-10Swarm.m4内部的负载平衡8-4warm三节点环境搭建.m4第9章Docker与odma更新描述.txt文档.zireadme.md9-1什么是Podma.m49-3DockervPodma实际操作不同.m49-4Podma.m4中od的基本操作9-2Podma安装及快速入门.m49-5Podma后续研究.m4第10章Docker的多架构支持更多课程微信客服.jg10-3dockeruildx命令搭建多架构镜像.m410-4章节概要.m410-2ARM环境的Docker演示.m410-1本章介绍.m4第11章Git和容器-CICD文档.zi11-2Dockerhu镜像构建自动化.m411-8通过GitHuActio.m4部署在线课程文档11-1本章介绍.m411-3GitHuActio.m4简介11-5GitHuActio构建和提交image.m411-4GitHuActioHelloWorld.m411-6GitHuActio实现uildx.m411-7修改uildxworkflow.m4第12章容器安全readme.md12-4容器运行监控.m412-1本章介绍.m412-3代码和图片漏洞扫描.m412-2Docker运行环境检查.m4第13章课程内容审查和高级建议13-1课程总结.m4docker...

2023-02-09 docker MD5 文件出错

编辑评论：Docker第一本df电子书是作者Jame写的一本关于Docker的书，主要介绍了安装Docker的方法，使用Docker镜像和仓库，使用Docker搭建服务，以及Docker编排和服务发现等。电子书内容简介Docker是一个开源应用程序容器引擎。开发者可以使用Docker将自己的应用程序和依赖包打包到一个可移植的容器中，然后发布到任何流行的Liux机器上。虚拟化也是可能的。这本书由Docker前服务和支持副总裁JameTurull撰写，是Docker开发指南。本书重点介绍Docker1.9及以上版本，引导读者完成Docker的安装、部署、管理和扩展，引导读者完成从测试到生产的整个开发生命周期，让读者了解Docker适合哪些场景。本书首先介绍了Docker及其组件的基础知识，然后介绍了使用Docker构建容器和服务来完成各种任务：使用Docker为新项目搭建测试环境，演示如何集成Docker使用持续集成工作流，构建应用服务和平台，如何使用Docker的API，如何扩展Docker。电子书作者简介Jame是一名技术作家和开源极客。他的杰作是TheLogStahBook，一本关于流行的开源日志工具的书。Jame还写了两本关于Puet的书，一本是ProPuet，另一本是更早的PulligStrigwithPuet：CofiguratioMaagemetMadeEay。此外，Jame还撰写了三本书，ProLiuxSytemAdmiitratio、ProNagio2.0和HardeigLiux。Jame是Kicktarter的首席技术官。此前，Jame曾担任Docker服务和支持副总裁、Vemo工程副总裁和PuetLa技术运营副总裁。第一本Docker书籍df章节预览第一章简介1.1Docker简介1.1.1提供了一种简单轻量的建模方法1.1.2职责的逻辑分离1.1.3快速高效的开发生命周期1.1.4鼓励使用面向服务的架构1.2Docker组件1.2.1Docker客户端和服务器1.2.2Docker镜像1.2.4容器1.3我可以用Docker做什么1.4Docker和配置管理1.5Docker的技术组件1.6本书内容1.7Docker资源第2章安装2.1安装Docker的先决条件2.2在Uutu和Deia中安装2.2.1检查先决条件2.2.2安装2.2.3Docker和2.3在RedHat和基于RedHat的发行版上安装2.3.1检查先决条件2.3.2安装2.3.3在RedHat发行版中启动Docker守护进程2.4在OSX中安装2.4.1在OSX中安装2.4.2在OSX中启动2.4.3测试2.5在Widow中安装2.5.1在Widow中安装2.5.2在Widow中启动2.5.3测试2.6使用本书的DockerToolox示例2.7Docker安装脚本2.8二进制安装2.9Docker守护进程2.9.1配置Docker守护进程2.9.2检查Docker守护进程是否正在运行2.10升级2.11Docker用户界面2.12总结第3章Docker入门3.1确保Docker准备就绪3.2运行我们的第一个容器3.3使用第一个容器3.4容器命名3.5重启停止的容器3.6附加到容器3.7创建守护进程容器3.8容器内部发生了什么3.9Docker日志驱动3.10查看容器中的进程3.11Docker统计3.12在容器内运行进程3.13停止守护进程容器3.14自动重启容器3.15深入容器3.16删除容器3.17总结第4章使用Docker映像和存储库4.1什么是Docker镜像4.2列出镜像4.3拉取图片4.4查找镜像4.5构建镜像4.5.1创建DockerHu帐户4.5.2使用Docker的commit命令创建镜像4.5.3使用Dockerfile构建镜像4.5.4基于Dockerfile构建新镜像4.5.5命令失败时会发生什么4.5.6Dockerfile和构建缓存4.5.7基于构建缓存的Dockerfile模板4.5.8查看新图片4.5.9从新镜像启动容器4.5.10Dockerfile指令4.6推送图片到4.7删除镜像4.8运行你自己的4.8.1从容器运行4.8.2测试新4.9其他可选注册服务4.10总结第5章在测试中的使用5.1使用Docker测试静态网站5.1.1示例网站初始化5.1.2搭建示例网站和Ngix镜像5.1.3从示例网站和Ngix图像构建容器5.1.4修改网站5.2使用Docker构建和测试We应用程序5.2.1构建Siatra应用程序5.2.2创建Siatra容器5.2.3扩展Siatra应用程序以使用5.2.4将Siatra应用程序连接到Redi容器5.2.5Docker内部网络5.2.7使用容器连接进行通信5.2.8连接容器小结5.3用于持续集成的Docker5.3.1构建Jeki和Docker服务器5.3.2创建新的Jeki作业5.3.3运行Jeki作业5.3.4与Jeki作业相关的后续步骤5.3.5Jeki设置总结5.4多配置5.4.1创建多个配置作业5.4.2测试多个配置作业5.4.3Jeki多配置作业总结5.5其他选项5.6总结第6章使用Docker构建服务6.1构建第一个应用程序6.1.1Jekyll基础镜像6.1.2构建Jekyll基础镜像6.1.3Aache镜像6.1.4构建JekyllAache镜像6.1.5启动Jekyll网站6.1.6更新Jekyll网站6.1.7备份Jekyll卷6.1.8扩展Jekyll示例站点6.2使用Docker构建Java应用服务6.2.1WAR文件获取程序6.2.2获取WAR文件6.2.3Tomecat7应用服务器6.2.4运行WAR文件6.2.5基于Tomcat应用服务器构建服务6.3多容器应用栈6.3.1Node.j镜像6.3.2Redi基础镜像6.3.3Redi主镜像6.3.4Redi复制镜像6.3.5创建Redi后端集群6.3.6创建节点容器6.3.7捕获应用程序日志6.3.8节点栈总结6.4不使用SSH管理Docker容器6.5总结第7章Docker编排和服务发现7.1.1安装7.1.2获取示例应用程序7.1.3docker-comoe.yml文件7.1.4运行7.1.5使用7.1.6撰写摘要7.2Coul、服务发现和7.2.1构建Coul镜像7.2.2在本地测试Coul容器7.2.3使用Docker运行Coul集群7.2.4启动具有自启动功能的Coul节点7.2.5启动剩余节点7.2.6使用Coul在Docker中运行分布式服务7.3.1安装7.3.2创建Swarm集群7.3.3创建容器7.3.4过滤器7.3.5政策7.3.6总结7.4其他编排工具和组件7.4.1舰队和7.5总结第8章使用8.2简介8.3测试8.3.1通过API管理Docker镜像8.3.2通过API管理Docker容器8.4改进的TProv应用程序8.5验证Docker远程API8.5.1建立证书颁发机构8.5.2创建服务器的证书签名请求和密钥8.5.3配置Docker守护进程8.5.4创建客户端证书和密钥8.5.5配置Docker客户端以启用身份验证8.6总结第9章获得帮助和改进Docker9.1获得帮助9.1.1Docker用户、开发邮件列表和论坛IRC上的9.1.2GitHu上的9.1.39.2报告Docker问题9.3设置构建环境9.3.1安装9.3.2安装源代码和构建工具9.3.3签出源代码9.3.4贡献文档9.3.5搭建开发环境9.3.6运行测试9.3.7在开发环境中使用9.3.8发起9.3.9合并和维护者的批准...

2022-05-10 镜像容器 镜像 容器 仓库

编辑评论：《Docker简介》由两部分组成：Docker概述和Docker技术。遵循简介-详解-命令的章节布局，全面系统地分析了Docker的基本原理和实际应用。清晰详细的操作步骤结合大量实际代码，为读者上手Docker保驾护航。图书特色从零基础开始，帮助读者快速建立Docker技术知识体系破茧成蝶，把复杂的逻辑解释清楚透彻覆盖面广，从安装入口到应用部署，展现Docker应用全景本书内容容器开发之路走进DockerDocker安装看DockerDocker引擎Docker镜像Docker容器应用程序的容器化使用DockerComoe部署应用程序码头工人群Docker网络Docker覆盖网络卷和持久数据使用DockerStack部署应用程序Docker安全企业版工具企业功能安全客户端和守护进程之间的通信DCA考试扩展总结这本书是一本关于Docker的介绍性书籍。全书分为17章。从Docker概述和Docker技术综合分析。以通俗易懂的方式介绍了Docker的相关知识，操作步骤清晰详细，并结合了大量实用的代码帮助。读者学以致用，将Docker知识应用到实际项目开发中。本书适合对Docker感兴趣的初学者、Docker技术开发人员、运维人员。本书也可以作为Docker认证工程师考试的参考书。过去的时光业务是基于应用程序（Alicatio）的操作。如果刘国申请失败，业务将无法正常运行，甚至会导致商业公司破产。这种情况是真实的，甚至每天都在发生。大多数应用程序都在服务器上运行。曾几何时，每个脚本只能运行一个应用程序。Widow和Liux操作系统都没有相应的技术手段来保证多个应用程序可以同时在单台服务器上稳定、安全地运行。在那些日子里，经常出现这样的情况，即业务部门每次想要创建一个新的应用程序时，IT部门都需要购买一台新服务器。在大多数情况下，没有人确切知道新应用程序所需的服务器性能将是多少，这意味着IT部门需要使用经验来猜测所购买服务器的型号和规格。因此，IT部门必须进行采购。购买性能明显优于您的业务需求的服务器。毕竟，无论是IT部门还是业务部门，都不想看到服务器性能不足的情况。由于服务器性能不足，一些交易可能会失败，而交易失败会导致公司失去客户，减少收入，所以D：“1部门通常会购买更大更好的服务器。这种做法导致大部分服务器运行在他们的长时间满负荷，在5%~10%的水平范围内。这是对公司资产和资源的巨大浪费！虚拟机不足但是总是有这个，一个但是！即使是像VM这样的伟大技术也远非完美！实际上，虚拟机的最大缺点是它们依赖于其专用的操作系统(OS)，这会消耗额外的CPU、RAM和存储资源，而这些资源本来可以用来运行更多的应用程序。每个操作系统都需要修补和监控。在某些情况下，O需要许可证才能运行。ivt运营成本(OPEX)和资本支出(CAPEX)都是浪费。虚拟机技术也面临一些严峻的挑战。比如虚拟机的启动通常比较慢，便携性也比较差。不同虚拟机管理器（Hyreiicor）或云平台之间的虚拟机迁移比预期的要困难得多。...

2022-05-06 虚拟机服务器管理器在哪里 外网访问vmware虚拟机服务器

编辑评论：SrigCloud与Docker微服务架构实战（第二版）基于SrigCloudEdgwareRELEASE和Docker17.09，旨在指导技术团队实现微服务架构实现，涵盖微服务理论、微服务服务开发框架（SrigCloud）和运行平台（Docker）三大主题编辑推荐适合人群：关注微服务架构、SrigCloud、分布式系统的从业者。SrigCloud的迅速崛起已成为微服务领域无可争议的标准来自SrigCloud社区赞助商的见解|布道者|微服务专家这个Java企业级微服务极致利器已经部署在所有互联网公司SrigCloud的快速发展需要你快速跟上新版本，了解新实践关于作者李舟，近8年软件系统开发经验，多年系统架构经验，对SrigCloud、微服务、持续集成、持续交付有一定的见解。热爱技术交流，曾代表公司参加全球微服务架构高峰论坛、QCo等技术沙龙；拥护开源，在GitHu和Git@OSC上开源了很多项目，如开源电子书《在实践中使用SrigCloud和Docker》微服务等，被开源中国推荐。微服务架构的优势微服务架构具有以下优点。易于开发和维护：微服务只关注特定的业务功能，因此业务清晰，代码少。开发和维护单个微服务相对简单。整个应用程序是由几个微服务构建的，因此整个应用程序将保持在可控状态。单个微服务启动速度更快：单个微服务的代码更少，因此启动速度会更快。部分修改易于部署：只要修改了单个应用程序，就必须重新部署整个应用程序。微服务解决了这个问题。一般来说，要修改一个微服务，只需要重新部署该服务即可。不受限制的技术栈：在微服务架构中，可以根据项目业务和团队的特点，合理选择技术栈。比如有些服务可以使用关系型数据库MySQL；部分微服务有图形计算需求，可以使用Neo4j；甚至有些微服务可以用Java开发，有些微服务可以用Node.j开发。按需伸缩：可根据需要实现细粒度伸缩。例如，如果系统中的微服务遇到瓶颈，可以根据微服务的业务特性增加内存、升级CPU、增加节点等。综上所述，单体应用架构的缺点恰恰是微服务的优点，而这些优点让微服务看起来很完美。然而，没有完美这回事，就像没有灵丹妙药一样。让我们讨论一下使用微服务带来的挑战。SrigCloud功能SrigCloud具有以下特点：约定优于配置。适用于各种环境。在PCServer或各种云环境（如阿里云、AWS等）上开发部署全部可用。隐藏组件的复杂性并提供声明式、无xml的配置。开箱即用，快速入门。轻量级组件。SrigCloud集成的大部分组件都是比较轻量级的，比如Eureka、Zuul等，都是各自领域的轻量级实现。组件丰富，功能齐全。SrigCloud对微服务架构提供了非常完善的支持，比如配置管理、服务发现、断路器、微服务网关等。选择中性而丰富。例如，SrigCloud支持使用Eureka、ZooKeeer或Coul进行服务发现。灵活。SrigCloud的组件解耦，开发者可以根据需要灵活选择技术选项...

2022-05-06 微服务系统架构 什么叫微服务架构

编辑评论：SrigCloud与Docker高并发微服务架构设计与实现从架构设计入手，结合实际情况讲解SrigCloud、Docker、Jeki等工具的具体使用方法，并给出一个以电商平台案例讲解如何将微服务架构的设计理念更好地应用到生产实践中。简介《SrigCloud与Docker高并发微服务架构设计与实现》从架构设计、应用开发和运维部署三个方面入手。全面阐述和实践了微服务架构设计的实现，并结合Productio实际讲解了如何使用SrigCloud、Docker、Jeki等工具。在《SrigCloud与Docker高并发微服务架构设计与实现》中，通过一个互联网电商平台实例实现了一个高并发微服务架构设计，并通过详细的开发和实现过程，演示了一个安全、可靠、稳定、高效和可持续的系统平台方法。《SrigCloud与Docker高并发微服务架构设计与实现》适合互联网应用开发者参考学习。关于作者陈绍建，资深IT技术专家，着有《SrigBoot深度实践》（机械工业出版社2016年10月）、《Neo4j全栈开发》（电子工业出版社2017年6月）等书籍。在化工技术、数据库使用与大数据分析、分布式架构设计、Srig等开源框架的使用、微服务实现与开发等领域有深入的研究和丰富的实践经验。未来研究方向：物联网、智慧城市、AI人工智能等。书籍章节本书由三部分组成，每一部分及其章节组织如下。第一部分：架构第一章微服务架构与SrigCloud第2章微服务架构最佳设计第三章电商平台微服务设计实例第二部分开发第四章开发工具选择与SrigBoot基础第五章电商平台微服务工程设计第6章微服务治理基础服务开发第7章RetAPI微服务开发第8章WeUI微服务开发第九章电商平台移动商城开发第10章商户管理背景和SSO设计第11章平台管理后端开发第三部分操作与维护第12章服务器架构设计和Docker使用第13章数据库集群设计与高可用读写分离实现第14章。分布式文件系统等基础设施安装和配置第15章使用自动构建工具Jeki实施CI/CD为什么要使用SrigCloud微服务架构的实现和使用经历了一定的过程。在这个过程中，亚马逊和Netlix在使用微服务架构设计方面的成功经验和成就是一个令人振奋的结果。尤其是NetlixOSS开源组件的推出，掀起了微服务浪潮。Srig团队在Netfixo的基础上推出了SrigCloud微服务开发工具套件，大大降低了微服务开发的门槛。使用SrigCloud工具套件，Java开发人员可以非常轻松地开发微服务应用程序。SrigCloud专注于为典型用例和可扩展性机制提供良好的开箱即用体验，涵盖以下功能方面。分布式版本化配置。服务注册和发现。路由。在服务之间调用。负载平衡。断路器。全局锁定。主机选举和集群状态。分布式消息传递。使用SrigCloud，开发微服务应用程序非常简单。使用SrigCloud，您可以在任何环境中进行开发和调试，包括您自己的笔记本电脑、您公司的LAN环境以及CloudFoudry等托管平台。...

2022-05-06 微服务架构 springcloud组件 微服务架构springcloud spring boot

编辑评论：Docker容器与容器云（第2版）以源码解读为基础，以搭建Docker云平台为目标，以实际项目中的问题解答为线索，全面解析Docker原理。这是国内第一本解读Docker原理，同时深入实践Docker套件和云平台三件套的书籍。也是国内第一本深入解读Kuerete的书籍。简介本书是第一版基于Docker1.10版和Kuerete1.2版的全面更新。站在从业者的角度，重点关注Docker和Kuerete，从《基本用法介绍》到《核心原理解读》再到《高级实用技能》的思路，一本书讲解了当前主流的容器和容器云技术，帮助读者在实际场景中使用Docker容器和容器云解决问题，启发新思维。本书分为两部分，第一部分是对Docker容器技术的深入解读，包括Docker架构与设计、核心源码解读和高级实战技巧；第二部分总结对比了三类基于Docker的主流容器云项目，包括专注于Docker容器编排和部署的容器云，专注于应用支持的容器云，以及万物皆容器的Kuerete，然后讲解了设计详细介绍了Kuerete核心源码的实现，并介绍了Kuerete在几个典型场景下的实践。本书适合有一定Docker基础的开发者、架构师、IT学生，以及正在探索基于Docker构建云计算平台的技术人员。也非常适合作为大学教材或培训教材。关于作者浙江大学软件工程实验室（SEL）云计算团队成立于2011年，组织博士、硕士生构建、分析和研究开源云计算技术，包括Docker、Kuerete、CloudFoudry、OeStack、CloudStack、Eucalytu、Covirt、OeShift等，积极为开源社区贡献代码，管理和参与线上线下讨论社区，出席国内外云计算技术峰会并发言。以开源社区为技术交流研发平台，浙大SELLa经过4年多的时间，已经成长为一支热情、有能力的云计算研发团队，同时也是国内外开源云计算社区，尤其是Docker、KuereteCloudFoudry社区得到了广泛的认可。书籍结构本书分为两部分，沿着从容器到容器云的开发路线，从“概念使用分析”到“核心原理分析”，再到“进阶实践技能”，层层递进，全面Docker介绍以及围绕Docker构建的各种容器云平台技术，深入剖析Kuerete背后的技术原理和设计思路。第一部分讲解Docker容器的核心原理和实战技巧。第1章和第2章让读者在短时间内体验IT界的风暴，对Docker的使用有一个初步的了解，为后续源码分析做铺垫。第三章是本书第一部分的核心。本章以Docker1.10源码为基础，深入剖析容器的命名空间和cgrou原理。然后我们以dockerru命令为线索，运行Docker的容器创建和镜像。组织、联合文件系统和容器网络初始化的源码，彻底透彻地向读者展示了Docker源码从一条指令到最终Liux容器生成的全过程的设计原理和执行路线。第4章介绍了当下“容器化思维”的趋势以及Docker相关的几类实用技能，包括网络、监控、服务发现等。值得一提的是，在阅读上述代码的过程中，本书几乎没有贴出任何内容Docker源代码或功能的一部分，但尽量用通俗易懂的语言和生动的插图来展示代码背后的执行逻辑和设计思想。Docker的源代码字面意思是字面意思，我们希望通过这种解读，让读者真正了解Docker和容器背后的设计方法和技术精髓，而不是把它变成一本简单的技术手册。第二部分深入分析了各种基于Docker的“容器云”平台背后的架构细节和设计理念。虽然这些容器云在底层技术上都是基于Docker等容器技术，但它们背后的设计思路却有着很大的不同。我们将看到一个颠覆原有la和Paa云计算生硬分类的辉煌容器云世界。第5章介绍了一种最简单的容器云解决方案作为介绍；第6章和第7章分析比较了几类典型的容器云开源项目，包括Docker官方的“三剑客”项目，FleetadMore类似于经典Paa的Fly和Dei；第八章是本书第二部分的重点。基于Kuerete1.2版本的源码，我们从核心概念到架构分析，再深入到Kuerete源码的组件级分析。这是国内第一次在这个维度详细讲解Kuerete容器云平台的各种技术细节。我们希望通过容器云平台的源码解读，带领读者从纷繁复杂的容器云项目中梳理出一个详细的脉络，让读者在选型和二次开发过程中减少困惑和试错成本发展。作为Kuerete项目的贡献者和特性维护者，我们希望更多的技术人员能够从源代码层面对Kuerete有更深入的了解和了解，与我们一起推动这个优秀的开源项目在中国的进步和发展.降落。在第二部分的最后，我们尝试回答之前关于容器云应该采取什么样的形态才能更好地支持当前时代的问题。信号和初始化过程内核还授予PID命名空间中的iit进程其他权限-信号屏蔽。如果在iit中没有处理信号的代码逻辑，那么与iit相同PID命名空间下的进程发送给它的信号（即使它具有超级权限）将被阻塞。该函数的主要作用是防止iit进程被误杀。那么，父节点的PID命名空间中的进程向子节点中的iit进程发送相同的信号，这个会被忽略吗？父节点中的进程发送的信号，如果不是SICKILL（销毁进程）或SICSTOP（挂起进程）也将被忽略。但是如果发送了SIGKILL或SIGSTOP，则会强制执行子节点的iit（不能通过代码抓包进行特殊处理），这意味着父节点中的进程有权终止子节点中的进程。一旦iit进程被销毁，相同PID命名空间中的其他进程在收到SIGKILL信号后也被销毁。理论上，PID命名空间不再存在。但是如果/roc/[id]//id被挂载或打开，命名空间将被保留。但是，保留的命名空间不能用于通过et()或fork()创建进程，因此它实际上并没有做任何事情。当容器中有多个进程时，容器中的iit进程可以捕获信号，当SIGTERM或SIGINT等信号到达时，会为其子进程保存信息并回收资源。在Dockerdaemo的源码中也可以看到类似的处理方式。当结束信号到来时，容器进程被终止，相应的资源被回收。...

2022-05-06 docker-init docker --init

书名：深入浅出docker作者：[英]奈吉尔·波尔顿出版社：人民邮电出版社出品方：异步图书原作名：DockerDeeDive译者：李瑞丰/刘康出版年：2019-3-1页数：270类别：计算机网络格式：df、eu、moiISBN：9787115504890《深入浅出docker》作者简介：NigelPoulto，DockerCatai专家，亚马逊畅销图书作者，存储专家，Docker技术先驱。Nigel有丰富的运维技术经验，著有多部容器相关的图书，并开设了视频培训课程，在业界有非常大的影响力。出版了《DockerDeeDive》《TheKuereteBook》等图书。《深入浅出docker》内容简介：本书是一本Docker入门图书，全书分为17章，从Docker概览和Docker技术两部分进行全面解析，深入浅出地介绍了Docker的相关知识，清晰详细的操作步骤结合大量的实际代码帮助读者学以致用，将Docker知识应用到真实的项目开发当中。本书适合对Docker感兴趣的入门新手、Docker技术开发人员以及运维人员阅读，本书也可作为Docker认证工程师考试的参考图书。...

2022-04-08 读书由浅入深的书单 深入浅出出版小说

作者：[美]乔?约翰斯顿（JoeJohto）[西]安东尼?巴彻勒（AtoiBatchelli）出版社：人民邮电出版社格式:AZW3,DOCX,EPUB,MOBI,PDF,TXTDocker生产环境实践指南试读：前言Docker是基础设施的新成员。很少有新兴技术能像它这样，在DevO和基础设施领域中快速风靡起来。在不到两年的时间内，Google、亚马逊、微软、IBM以及几乎所有云供应商都宣布支持运行Docker容器。大量与Docker相关的创业公司在2014年和2015年年初都获得了风险资本的投资。Docker开源技术背后的同名公司——Docker公司，在2015年第一季度的D轮融资中估值为10亿美元左右。大大小小的公司都在转换其应用，使之运行于容器内，以此实现面向服务架构（SOA）和微服务。不论是参加从旧金山到柏林的任何DevO聚会，还是阅读最热门的公司工程博客，都可以看出全世界的运维领导者们如今都在云上运行Docker。毫无疑问，容器已经成为应用程序打包和基础设施自动化的重要组成部分。但有一个棘手的问题，促使本书作者和同僚们创作了另一本Docker图书。本书面向的读者具有中高级DevO和运维背景的读者将从本书获益最多。因而，强烈建议读者应具备在生产环境中运行服务器以及创建和管理容器这两方面的基本经验。很多图书和博客文章已经涵盖了与Docker安装及运行相关的话题，但能把在生产环境中运行Docker时产生的大量甚至是令人挠头的关注点结合在一起的材料则少之又少。不用担心，如果你很喜欢《盗梦空间》（Icetio）这部电影，在云服务器的虚拟机中运行容器会让你感觉很自然。本书将带读者深入理解生产环境中架构的组成部分、关注点，以及如何运行基于Docker的基础设施。谁真的在生产环境中使用Docker换个更深刻的说法，对于在真实生产环境中使用Docker遇到的问题，如何找到解决之道？本书综合了访谈、真实公司端到端的生产环境实例，以及来自DevO杰出专家的参考文献，以此来解答这些问题。虽然本书包含了一些有用的示例，但它并不是一本复制粘贴的“教程式”参考书。相反，本书侧重于生产环境中对前沿技术进行评估、风险抵御及运维所需的实践理论和经验。作为作者，我们希望这本书所包含的内容能够为那些正在评估如何及何时将Docker相关技术引入其DevO栈的团队提供一个可靠的决策指南，这远比代码片段要来得长久。生产环境中运行的Docker为企业提供了多个新的运行和管理服务器端软件的方式。很多现成的用例讲解了如何使用Docker，但很少有公司公开分享过他们的全栈生产环境经验。本书汇集了作者在生产环境中运行Docker的多个实例和一组选定的友好公司分享的使用经验。为什么使用DockerDocker所使用的底层容器技术已经存在了很多年，甚至早于dotCloud这家平台即服务（PaaS）创业公司，即后来我们所熟知的Docker。在dotCloud之前，许多知名的公司（如Heroku和Iro.io）已经在生产环境中运行大型容器集群，以获取额外的超越虚拟机的性能优势。与虚拟机相比，在容器中运行软件赋予了这些公司秒级而非分钟级的实例启动与停止的能力，同时能使用更少的机器运行更多实例。既然这项技术并不新鲜，为什么Docker能获得如此巨大的成功呢？主要是因为它的易用性。Docker创造了一种统一的方式，通过简便的命令行及HTTPAPI工具来打包、运行和维护容器。这种简化降低了将应用程序及其运行时环境打包成一个自包含镜像的入门门槛，使之变得可行且有趣，而不需要类似Chef、Puet及Caitrao之类的配置管理和发布系统。Docker提供了一种统一手段，将应用程序及其运行时环境打包到一个简单的Dockerfile里，这从根本上改变了开发人员与DevO团队之间的交互界面。从而极大简化了开发团队与DevO之间的沟通需求与责任边界。在Docker出现之前，各个公司的开发与运维团队之间经常会爆发史诗般的战争。开发团队想要快速前进，整合最新版的软件及依赖，以及持续部署。运维团队则以保证稳定为己任，他们负责把关可以运行于生产环境中的内容。如果运维团队对新的依赖或需求感到不适，他们通常会站在保守的立场上，要求开发人员使用旧版软件以确保糟糕的代码不会搞垮整台服务器。Docker一下子改变了DevO的决策思维，从“基本上说不”变成了“好的，只要运行在Docker中就可以”，因为糟糕的代码只会让容器崩溃，而不会影响到同一服务器上的其他服务。在这种泛型中，DevO有效地负责为开发人员提供PaaS，而开发人员负责保证其代码能正常运行。如今，很多团队将开发人员加入到PagerDuty中，以监控他们在生产环境中的代码，让DevO和运维人员专注于平台的稳定运行及安全。开发环境与生产环境对大多数团队而言，采用Docker是受开发人员更快的迭代和发布周期需求推动的。这对于开发环境是非常有益的，但对于生产环境，在单台宿主机上运行多个Docker容器可能会导致安全漏洞，这一点我们将在第6章“安全”中讲述。事实上，几乎所有关于在生产环境中运行Docker的话题都是围绕着将开发环境与生产环境区分开的两个关注点进行的：一是编排，二是安全。有些团队试图让开发环境和生产环境尽可能保持一致。这种方法看起来很好，但是限于开发环境这样做所需定制工具的数量又或者说模拟云服务（如AWS）的复杂度，这种方法并不实际。为了简化这本书的范畴，我们将介绍一些部署代码的用例，但判定最佳开发环境设置的实践机会将留给读者。作为基本原则之一，尽量保持生产环境和开发环境的相似性，并使用一个持续集成/持续交付（CI/CD）系统以获取最佳结果。我们所说的“生产环境”对于不同的团队，生产环境意味着不同的东西。在本书中，我们所说的生产环境是指真实客户用于运行代码的环境。这是相对于开发环境、预演环境及测试环境而言的，后者的停机时间不会被客户感知到。在生产环境中，Docker有时是用于接收公共网络流量的容器，有时则是用于处理来自队列负荷的异步的后台作业。不管哪种用途，在生产环境中运行Docker与在其他环境中运行相比，最主要的差异都是需要在其安全性与稳定性上投入较多的注意力。编写本书的动力之一是，与Docker相关的文档和博客文章中缺乏对实际生产环境与其他环境的明确区分。我们认为，80%的Docker博客文章中的建议在尝试在生产环境中运行6个月之后会被放弃（或至少修改）。为什么？因为大多数博客文章中举的都是理想化的例子，使用了最新、最好用的工具，一旦某个极端的情况变成了致命缺陷，这些工具将被遗弃（或延期），被更简单的方法所取代。这是Docker技术生态系统现状的一个反映，而非技术博客的缺陷。总的来说，生产环境很难管理。Docker简化了从开发到生产的工作流程，但同时增加了安全和编排的复杂度（更多关于编排的内容参见第4章）。为了节省时间，下面给出本书的重点综述。所有在生产环境中运行Docker的团队，都会在传统的安全最佳实践上做出一项或多项妥协。如果无法完全信任容器内运行的代码，那么就只得选用容器与虚拟机一对一的拓扑方式。对于很多团队而言，在生产环境中运行Docker的优势远远大于其带来的安全与编排问题。如果遇到工具方面的问题，请等待一到两个月，以便Docker社区对其进行修复，不要浪费时间去修补其他人的工具。保持Docker设置最小化。让一切自动化。最后，对成熟的编排工具（如Meo、Kuerate等）的需求远比想象的要少得多。功能内置与组合工具Docker社区一个常见的口头禅是“电池内置但可移除”，指的是将很多功能捆绑在一起的单体二进制文件，这有别于传统Uix哲学下相对较小、功能单一、管道化的二进制文件。这种单体式的做法是由两个主要因素决定的：（1）使Docker易于开箱即用；（2）Golag缺少动态链接。Docker及多数相关工具都是用Google的Go编程语言编写的，该语言可以简化高并发代码的编写与部署。虽然Go是一门出色的编程语言，但用它来构建的Docker生态系统中也因此迟迟无法实现一个可插拔的架构，在这种架构中可以很容易用替代品对工具进行更换。如果读者有Uix系统背景，最好是编译自己的精简版Docker守护进程，以符合生产环境的需求。如果读者有开发背景，预计到2015[1]年下半年，Docker插件将成为现实。在此期间，估计Docker生态系统中的工具将会出现明显的重叠现象，某些情况下甚至是相互排斥的。换句话说，要让Docker运行于生产环境中，用户的一半工作将是决定哪些工具对自己的技术栈最有意义。与DevO所有事情一样，先从最简单的解决方案入手，然后在必要时增加其复杂性。2015年5月，Docker公司发布了Comoe、Machie及Swarm，与Docker生态系统内的同类工具进行竞争。所有这些工具都是可选的，请根据实际情况对其进行评估，而不要认为Docker公司提供的工具就一定是最佳解决方案。探索Docker生态系统时的另一项关键建议是：评估每个开源工具的资金来源及其商业目标。目前，Docker公司和CoreOS经常发布工具，以争夺关注度和市场份额。一个新工具发布后，最好等上几个月，看看社区的反应，不要因为它看起来很酷就切换到最新、最好用的工具上。哪些东西不要Docker化最后一个关键点是，不要期望能在Docker容器中运行所有东西。Heroku风格的“十二要素”（12factor）应用是最容易Docker化的，因为它们不维护状态。在理想的微服务环境中，容器能在几毫秒内启动、停止而不影响集群的健康或应用程序的状态。类似CluterHQ这样的创业公司正着手实现Docker化数据库和有状态的应用程序，但眼下，由于编排和性能方面的原因，可能需要继续直接在虚拟机或裸机上运行数据库。[2]Docker还不适用于任何需要动态调整CPU和内存要求的应用。允许动态调整的代码已经完成，但尚不清楚何时才能在一般的生产环境中投入使用。目前，若对容器的CPU和内存的限制进行调整，需要停止并重新启动容器。另外，对网络吞吐量有高要求的应用进行最佳优化时不要使用Docker，因为Docker使用itale来完成宿主机IP到容器IP的NAT转换。通过禁用Docker的NAT来提升网络性能是可行的，但这是一个高级的使用场景，很少有团队会在生产环境中这么做。技术审稿人衷心感谢以下技术审稿人提供的早期反馈及细致的评论：MikaTurue、XavierBruhiere和FelixRae。[1]Docker1.7版中正式引入了插件系统。——译者注[2]Docker1.10版中新增的dockerudate命令可实现CPU和内存的动态调整。——译者注第1章入门建立Docker生产环境系统的首要任务，是以一个有助于想象各组件如何相互配合的方式来理解其术语。与其他快速发展的技术生态系统一样，我们可以预见，Docker野心勃勃的市场营销、不完善的文档以及过时的博客文章将造成使用者对各个工具职责理解上的混乱。我们将在本章中定义贯穿全书的术语和概念，而非提供一份统一的Docker百科全书。通常情况下，我们的定义与生态系统中的大体一致，但如果你所阅读的博客文章中使用了不同的术语也不用太过惊讶。在本章中，我们将介绍在生产环境中运行Docker的核心概念以及不涉及具体技术的容器常识。在随后的章节中，我们将讨论真实世界的生产环境用例，并详细说明其组件和供应商信息。1.1术语下面让我们来看一下本书所采用的Docker术语。1.1.1镜像与容器●镜像是指文件系统快照或tar包。●容器是指镜像的运行态。1.1.2容器与虚拟机●虚拟机持有整个操作系统和应用程序的快照。●虚拟机运行着自己的内核。●虚拟机可以运行Liux之外的其他操作系统。●容器只持有应用程序，不过应用程序的概念可以延伸到整个Liux发行版。●容器共享宿主机的内核。●容器只能运行Liux，不过在同一宿主机上运行的每个容器都可包含不同的发行版。1.1.3持续集成/持续交付在应用程序新代码提交或触发其他条件时，系统自动构建新镜像并进行部署。1.1.4宿主机管理设置/配备一台物理服务器或虚拟机以便用于运行Docker容器的过程。1.1.5编排编排（orchetratio，也称编配）这个术语在Docker生态系统中有多种含义。通常情况下，它包括调度和集群管理，不过有时也包括了宿主机管理。在本书中，我们将编排作为一个松散的总称，包括容器调度的过程、集群的管理、容器的链接（发现），以及网络流量路由。或者换句话说，编排是个控制器进程，用于决定在哪里运行容器，以及如何让集群知道可用的服务。1.1.6调度用于决定哪些容器可以以给定的资源约束（如CPU、内存和IO）运行在哪些宿主机上。1.1.7发现容器如何公开服务给集群，以及发现如何查找其他服务并与之通信的过程。举个简单的用例：一个网站应用容器发现如何连接到数据库服务。Docker文档中的发现是指将容器链接在一起，不过在生产级系统中，通常使用的是更复杂的发现机制。1.1.8配置管理配置管理过去常常指的是Docker出现之前的自动化工具，如Chef和Puet。大多数的DevO团队正在转移到Docker上，以消除这类配置管理系统的复杂度。在本书的示例中，配置管理工具只用于配备具有Docker和少量其他东西的宿主机。1.2从开发环境到生产环境本书着重于生产环境或非开发环境中的Docker，这意味着我们不会花太多的篇幅在开发环境中Docker的配置和运行上。但由于所有服务器都在运行代码，如何看待在Docker和非Docker系统中的应用程序代码还是值得简单讨论一下的。与Chef、Puet和Aile这类传统配置系统不同，Docker最好的使用方式是将应用程序代码预先打包成一个Docker镜像。镜像通常包含所有的应用程序代码、运行时的依赖以及系统的需求。而包含数据库凭证和其他敏感信息的配置文件通常在运行时添加，而非内建到镜像中。有些团队会在开发机上手工构建Docker镜像，然后推送到镜像仓库，之后再从仓库中拉取镜像到生产环境宿主机中。这是个很简单的用例。虽然行得通，但从工作流和安全角度考虑并不理想。一个更常见的生产环境示例是，使用持续集成/持续交付系统在应用程序代码或Dockerfile文件发生变更时自动构建新镜像。1.3使用Docker的多种方式过去的几年时间，科技发生了巨大变化，从物理服务器到虚拟服务器，再到拥有PaaS环境的云计算。不论是否采用了全新架构，Docker镜像都可以在当前环境中很容易地被使用。要使用Docker，并不需要立即从单体应用程序迁移到面向服务架构。有很多用例允许在不同层次上集成Docker。Docker常用于以下场景。●使用以镜像为基础的部署方式取代类似Caitrao的代码部署系统。●安全地在同一台服务器中运行遗留应用和新应用。●使用一个工具链循序渐进地迁移到面向服务架构。●管理云端或裸机上的水平扩展性和弹性。●确保从开发环境到预演环境到生产环境跨环境的一致性。●简化开发人员的机器设置和一致性。将应用的后台程序迁移到Docker集群中，同时保持网页服务器和数据库服务器不变是开始使用Docker的常见示例。另一示例是将应用的部分RESTAPI迁移到Docker中运行，前端使用Ngix代理在遗留服务和Docker集群之间路由通信。通过使用此类技术，团队可以渐进式地从单体应用无缝地迁移到面向服务架构。如今的应用程序往往需要几十个第三方库，用于加速功能开发或连接第三方SaaS和数据库服务。每个库都可能产生ug，或是让用户陷入版本依赖的泥沼。再加上库的频繁更改，要在基础设施上完成工作代码的持续部署而不引起失败，压力巨大。Docker可贵的镜像思想使得技术团队在部署工作代码时，不论是单体架构、面向服务或是二者的混合，由于代码及其依赖项捆绑在同一个镜像中，所使用的方式对每次部署都是可测试、可重复、文档化且一致的。一旦一个镜像构建完毕，就可以部署到任意多个运行着Docker守护进程的服务器上。另外一个常见的Docker用例是跨环境部署一个单一容器，其典型的代码路径是从开发环境到预演环境再到生产环境。容器为整个代码路径提供了一个一致的、可测试的环境。作为一个开发人员，Docker模型允许在其个人电脑上调试与生产环境完全一致的代码。开发人员可以很容易地下载、运行和调试有问题的生产环境镜像，且无需事先对本地开发环境进行修改。1.4可预期的情况在生产环境中运行Docker容器困难不小，但还是能实现的。每天都有越来越多公司开始在生产环境中运行Docker。如同所有的基础设施一样，我们建议以小规模入手，然后渐进式地完成迁移。为什么Docker在生产环境如此困难对生产环境有很多要求：安全可靠的部署、健康检查、最小或零停机时间、从失败中恢复的能力（回滚）、一个集中存储日志的方式、一种分析或调试应用的方式，以及一种聚合监控参数的方式。类似Docker这样的新技术虽然使用起来非常有趣，但还需要时间来完善。Docker在可移植性、一致性以及打包具有众多依赖的服务这些方面非常有优势。多数团队会因为以下一个或多个痛点而坚持使用Docker。●一个应用的不同部分使用大量不同的依赖。●支持使用旧依赖的遗留应用程序。●开发团队与DevO之间的工作流问题。本书中我们所采访的团队，有一个共同的警示：切勿尝试在一个组织内让采用Docker这事一蹴而就。即便运维团队已经为采用Docker做好了充分的准备，也请记住，过渡到Docker通常意味着将管理依赖的重任推给了开发人员。虽然很多开发人员都渴求这种自主权，以便加快迭代，但并非每位开发人员都有能力或兴趣将其列入自己的责任范围。为了能有一个良好的Docker工作流，还是需要花些时间来转变企业文化。在第2章中，我们将阐述Docker的技术栈。第2章技术栈生产环境的Docker设置包括了一些基本的架构组件，这些组件对运行容器化的及传统的服务器集群来说是通用的。在很多方面，可以简单地认为构建和运行容器的方式与当前构建和运行虚拟机的方式是一样的，只是使用了一套新的工具和技术。（1）构建并保存镜像快照。（2）将镜像上传到仓库中。（3）下载镜像到某台宿主机中。（4）以容器方式运行镜像。（5）将容器连接到其他服务上。（6）路由流量到容器中。（7）将容器日志发送到指定位置。（8）监控容器。与虚拟机不同的是，容器通过将宿主机（裸机或虚拟机）与应用程序服务隔离，从而提供了更高的灵活性。这为构建和配备流程带来了直接的改善，但由于额外的容器嵌入层，会增加一些开销。典型的Docker技术栈将包括用于解决以下关注点的组件：●构建系统；●镜像仓库；●宿主机管理；●配置管理；●部署；●编排；●日志；●监控。2.1构建系统●如何构建镜像，并将其推送到镜像仓库中？●Dockerfile位于何处？构建Docker镜像通常有以下两种方式。（1）在开发人员电脑上手工构建，然后推送到到仓库中。（2）使用CI/CD系统在代码提交时自动构建。理想的Docker生产环境将使用类似Jeki或Codehi这样的CI/CD（配置集成/持续部署）系统，在代码提交时自动构建镜像。一旦容器构建完毕，它将被发送到镜像仓库中，自动化测试系统就可以从中下载并运行该镜像。2.2镜像仓库●Docker镜像保存在哪里？当前的Docker镜像仓库可靠性比较差，但是每个月都在改善。Docker官方的镜像仓库中心是众所周知的不可靠，需要额外的重试和故障保护措施。多数团队一般会在自己的基础设施上运行私有的镜像仓库，以减少网络传输成本和延迟。2.3宿主机管理●如何配备宿主机？●如何升级宿主机？由于Docker镜像包含了应用及其依赖，宿主机管理系统通常只需要添加新服务器，配置访问权限和防火墙，并安装Docker守护进程即可。类似亚马逊的EC2CotaierService这类服务将消除对传统宿主机管理的依赖。2.4配置管理●如何定义容器的集群？●如何处理宿主机和容器运行时的配置？●如何管理密钥和机密信息？一个基本规则是：尽量避免使用传统的配置管理系统。其增加的复杂性往往会造成故障。Aile、SaltStack、Chef或Puet这类工具仅用于配备带有Docker守护进程的宿主机。尽可能试着摆脱对旧的配置管理系统的依赖，并使用本书所述的发现和集群技术转移到自我配置的容器上。2.5部署●如何将容器放置在宿主机上？镜像部署有以下两种基本方法。（1）推送——部署或编排系统将镜像推送给相关宿主机。（2）拉取——事先或按需从镜像仓库拉取镜像。2.6编排●如何将容器组织成集群？●在哪些服务器上运行容器？●如何调度服务器资源？●如何运行容器？●如何将流量路由给容器？●如何让容器公开和发现服务？“编排=强力胶带”。至少多数情况下可以这么认为。市面上有很多处于早期阶段的全功能容器编排系统，如DockerSwarm、Kuerete、Meo和Fly。但对大多数团队而言，这些系统通常过于强大，增加了在生产环境中出现问题时调试的复杂度。决定使用哪个工具来完成编排常常是设置和运行Docker中最艰难的部分。在第3章中，我们将讲述Peerace所采取的一种构建Docker系统的简约方法。第3章示例：极简环境一说起生产环境中容器的使用，大家的第一反应是那些在同样量级的宿主机上部署成千上万容器的大型公司。但实际上恰恰相反，要发挥容器的作用，并不需要构建如此庞大的系统。小规模的团队反而能从容器中获得最大收益，因为容器使构建和部署服务不仅变得简单，而且可重复、可扩展。本章描述的就是一家名为PeerSace的小规模公司构建系统时采取的一种极简方式。这种极简方式使他们能在短时间内使用有限的资源开辟一个新市场，并自始至终保持着极高的开发速度。PeerSace构建系统时的目标是既要易于开发，又要在生产环境中足够稳定。这两个目标通常是相互矛盾的，因为高速开发引起的大量变化反过来会对系统的构建和配置产生很大影响。任何一个有经验的系统管理员都知道，这样的变化率必然导致不稳定性。Docker看起来非常适合用在刚起步的时候，因为它既对开发人员友好，又支持以敏捷的方式构建和运维系统。Docker简化了开发和系统配置的某些方面，但有时却过于简单化了。在易于开发和稳健运维之间取得平衡不是件容易的事。3.1保持各部分的简单PeerSace实现开发速度和稳定的生产环境这两个目标的方法之一是拥抱简单。这里所说的简单是指系统的每个部分——容器——有且只有一个目标。这个目标就是：相同的过程，如日志收集，在任何地方都以相同的方式完成，而各部分连接的方法也是明确、静态地定义在配置文件中的。在这种简单的系统中，开发人员可以同步地、独立地构建系统的不同部分，并确信构建的容器可组装在一起。另外，在生产环境出现问题时，简单性也让问题的排查与解决变得非常简单。要长期保持系统的简单，需要大量的思考、折中和坚持，但最终这种简单将物有所值。PeerSace的系统由20个零散的微服务组成，其中有部分使用了MogoDB数据库和/或ElaticSearch搜索引擎。该系统设计遵循下列指导原则。（1）倾向无状态服务。这可能是简化PeerSace生产环境时最大的决策：大部分服务都是无状态的。除了用于处理当前进行中的请求的临时信息，无状态服务不需要保持任何需要持久化的数据。无状态服务的优势在于可以非常容易地对他们进行销毁、重启、复制及伸缩，所有这一切都无需考虑任何数据处理方面的逻辑。并且，无状态服务更易于编写。（2）倾向静态配置。所有宿主机和服务的配置都是静态的：一旦给服务器推送一项配置，该配置就会一直生效，直至显式地推送来新配置。与之相对的是那些动态配置的系统，其系统的实际配置是实时生成的，并会根据不同因素（如可用宿主机和即将到达的负载）进行自主修改。尽管动态系统的伸缩性更好，并且具有一些有趣的属性，如在出现某些故障时自动恢复等，但静态配置更易于理解和排错。（3）倾向静态的网络布局。如果在一台宿主机中找到一项服务，除非新配置被确定并提交，否则总能在那台宿主机中找到该服务。（4）区别对待无状态和有状态服务。尽管PeerSace的多数服务是无状态的，他们还是使用MogoDB和ElaticSearch来持久化数据。这两种类型的服务在本质上是非常不同的，应该区别处理。例如，将一个无状态服务从一台宿主机移动到另一台上非常简单，只需要启动新服务，然后停止旧服务即可。但要对一个数据库进行移动，数据也要跟着移动。移动数据可能会花费很长时间，要求在迁移过程中停止服务，或通过设备方法进行在线迁移。在开发领域，通常将无状态服务比做“牲口”，它们没有名字，很容易被代替和伸缩，而将有状态服务比做“宠物”，它们是唯一的、具名的，需要维护，并且难以伸缩。幸运的是，PeerSace正如一个农场一样，其“牲口”数量要远远多于“宠物”。以上这些设计原则是简化PeerSace系统的基础。将有状态服务与无状态服务分离，可以对本质上完全不同的服务进行区别处理（如图3-1所示），因此可以对每一种情况的处理方式进行优化和尽可能地简化。使用静态配置运行无状态服务使得操作系统的流程变得非常简单：多数情况下流程被简化成文件复制和容器重启，完全不需要考虑其他因素，如对第三方系统的依赖。图3-1上述设计准则能否产生一个简单的系统，完全取决于系统操作是否同样简单。3.2保持流程的简单在设计业务流程时，PeerSace基于观察做出了如下假定：在他们的基础设施中离硬件越近的层变更越少，而越接近终端用户的层变更越频繁（如图3-2所示）。图3-2根据这一观察，生产环境中的服务器数量很少变更，通常是由于缩放问题或硬件故障。而这些服务器的配置变更频次可能更高一些，通常是由于性能补丁、系统错误修复或安全问题等原因。在这些服务器上运行的服务数量和类别变更更为频繁。通常是指移动服务、添加新类型服务或对数据进行操作。这个层级上的其他修改可能与要求重新配置或变更第三方服务的新版本部署有关。不过，这类变更仍然不是很常见。在这样的基础设施中，多数的变更与多个服务的新版本推送有关。每天，PeerSace都会执行很多次新版服务的部署。多数情况下，新版本的推送只是简单地将现有版本替换成运行新镜像的新版本。有时也会使用相同镜像，但对配置参数进行变更。PeerSace的流程建立是为了让最频繁的变更最容易也最简单进行，即便这样会造成基础设施更难以变更（实际上并未发生）。3.3系统细节PeerSace运行着3个类生产环境集群：集成环境、预演环境与生产环境。每个集群包含了相同数量的服务，并使用相同的方式进行配置，唯一不同的是它们的原始性能（CPU、内存等）。开发人员同样会在自己的电脑上运行全部或部分集群。每个集群由以下几个部分组成：●几台运行着CetOS7的Docker宿主机，使用ytemd作为系统管理程序；●一台MogoDB服务器或一个复制集合；●一台ElaticSearch服务器或一个集群。MogoDB和/或ElaticSearch服务器可能在某些环境中是Docker化的，而在其他环境中不是Docker化的（如图3-3所示）。它们也会在多个环境中共享。在生产环境中，出于运维和性能的原因，这些数据服务是不做Docker化的。图3-3每个Docker宿主机运行着一个服务的静态集合，所有这些服务都会遵循如下模式进行构建：●所有配置都通过环境变量进行设置，包括其他服务的地址（和端口）；●不将数据写入磁盘；●将日志发送到标准输出（tdout）中；●生命周期由ytemd管理，并定义在一个ytemd单元文件中。利用ytemd所有服务都由ytemd管理。ytemd是一个借鉴了OSXlauchd的服务管理程序，此外，ytemd使用普通数据文件命名单元来定义每个服务的生命周期（如图3-4所示），这与其他使用hell脚本完成这类事务的传统管理程序完全不同。图3-4PeerSace的服务只将Docker进程当作唯一的运行时的依赖。ytemd的依赖管理只用来确保Docker处于运行状态，但不确保其拥有的服务以正确顺序启动。服务构建时要求它们可以以任何顺序启动。所有服务都由以下部分组成（如图3-5所示）：●一个容器镜像；●一个ytemd单元文件；●一个该容器专用的环境变量文件；●一组用于全局配置参数的共享环境变量文件。图3-5所有单元都遵循相同的结构。在服务启动之前，一系列包含环境变量的文件将被加载：EvirometFile=/ur/etc/ervice-locatio.evEvirometFile=/ur/etc/ervice-cofig.evEvirometFile=/ur/etc/cluter.evEvirometFile=/ur/etc/ecret.evEvirometFile=/ur/etc/%.ev这确保了每个服务会加载一系列通用环境文件（ervice-locatio.ev、ervice-cofig.ev、cluter.ev及ecret.ev），外加一个专用于该服务的文件：%.ev，此处的%在运行时将被替换成该单元的全称。例如，一个名为docker-earch的服务单元将被替换成docker-earch.ervice。接下来的条目是确保在启动新容器前旧容器被正确删除的：ExecStartPre=-/i/dockerkill%ExecStartPre=-/i/dockerrm-f%通过使用%，将容器命名为单元的全称。使用变量进行容器命名能让单元文件更通用并且可移植。在docker程序路径之前使用“-”可防止单元在命令失败时中止启动。这里需要忽略潜在的错误，因为如果此前不存在该容器，这些命令将执行失败，而这种情况又是合法的。单元中主要的条目是ExecStart，它将告之ytemd如何启动该容器。这里内容较多，但我们只关注一下其最重要的部分：ExecStart=/i/docker\ru\-"${APP_PORT}:${APP_PORT}"\-e"APP_PORT=${APP_PORT}"\-e"SERVICE_C_HOST=${SERVICE_C_HOST}"\-e"SERVICE_D_HOST=${SERIVCE_D_HOST}"\-e"SERVICE_M_HOST=${SERVICE_M_HOST}"\--add-hotdocker01:${DOCKER01_IP}\--add-hotdocker02:${DOCKER02_IP}\--volume/ur/local/docker-data/%/d:/data/data\--volume/ur/local/docker-data/%/log:/data/log\--ame%\${IMAGE_NAME}:${IMAGE_TAG}（1）使用EvirometFile加载的环境变量来配置容器（如通过-公开的端口）。（2）将集群中的其他宿主机地址添加到容器的/etc/hot文件中（--add-hot）。（3）映射用于日志和数据的数据卷。这主要是作为一个“蜜罐”[1]（hoeyot），以便检查这些目录并确保无人对其进行写入。（4）镜像自身（名称和版本）来自于从/ur/etc/%.ev中加载的环境变量，在本示例中它将映射到/ur/etc/docker-earch.ervice.ev中。最后，是一些定义如何停止容器及其他生命周期要素的条目：ExecSto=-/i/dockerto%Retart=o-failureRetartSec=1TimeoutStartSec=120TimeoutStoSec=303.4集群范围的配置、通用配置及本地配置PeerSace将集群配置分成两种类型文件：环境变量文件和ytemd单元文件。上面已经讲述了单元文件及其加载环境变量文件的方式，接下来看一下环境文件。将环境变量分解到不同文件中的主要原因在于，这些文件在跨集群时是否需要修改以及如何修改，不过也有其他操作层面的原因。●ervice-locatio.ev：集群中所有服务的宿主机名。这个文件在不同集群里通常是一样，不过也有例外。●ervice-cofig.ev：与服务自身相关的配置。如果不同集群运行的是服务的兼容性版本，这个文件应该是一样的。●ecret.ev：密钥信息。因其内容关系，这个文件被处理的方法与其他文件不同，而且在不同集群上也有差异。●cluter.ev：包括了集群间的所有不同之处，如所使用的数据库前缀、是测试还是生产环境、外部地址等。这个文件中最重要的信息是属于该集群的所有宿主机的IP地址。下面是某些示例集群中的文件。这是cluter.ev文件：CLUSTER_ID=alhaCLUSTER_TYPE="tet"DOCKER01_IP=x.x.x.226DOCKER02_IP=x.x.x.144EXTERNAL_ADDRESS=htt://omethigorother.comLOG_STORE_HOST=x.x.x.201LOG_STORE_PORT=9200MONGODB_PREFIX=alhaMONGODB_HOST_01=x.x.x.177MONGODB_HOST_02=x.x.x.299MONGODB_REPLICA_SET_ID=r001这是ervice-locatio.ev文件：SERVICE_A_HOST=docker01SERVICE_B_HOST=docker03CLIENTLOG_HOST=docker02SERIVCE_D_HOST=docker01...SERVICE_Y_HOST=docker03SERVICE_Z_HOST=docker01每个ytemd单元都包含集群中其他宿主机的引用，而这些引用来自于环境变量。包含服务宿主机名的变量会被装配到Docker命令中，以便容器进程使用。这是通过-e参数实现的，如-e"SERVICE_D_HOST=${SERIVCE_D_HOST}"。Docker宿主机的IP地址也同样通过--add-hotdocker01:${DOCKER01_IP}注入到容器中。这样，只需要修改这两个文件并且保持单元文件的完好无损，就可以将容器扩散到不同数量的宿主机中。3.5部署服务容器级别或配置级别的修改通过3个步骤完成：第1步，在配置仓库（Git）上做修改；第2步，将配置文件复制到宿主机的预演区域（h）；第3步，运行宿主机上的一个脚本来逐一部署每个服务，使得配置修改生效。这种方法提供了版本化配置，一次只推送一项相关配置，以及让推送配置生效的一种灵活方式。如果需要针对一组服务进行修改，首先在Git上做修改并提交。然后运行脚本，将这个配置推送到所有宿主机的预演区域。一旦配置被推送过去，在每台宿主机上运行一个脚本来部署或重部署该宿主机上的所有容器集合。这个脚本会对在列的所有服务执行如下命令。（1）将配置文件从预演区域复制到其最终位置：●ytemd单元文件；●共享的配置文件；●当前服务的配置文件；●密钥文件（解密后的）。（2）需要的话下载镜像文件（镜像定义在服务自身的配置文件中）。（3）重载ytemd的配置，以便读取新的单元文件。（4）重启容器对应的ytemd单元。PeerSace具有两个部署工作流，理解这一点有助于阐述其部署流程：一个用于开发环境，另一个用于生产环境，而后者是前者的一个超集。在开发过程中，他们会通过以下步骤将临时构建联署到集成服务器中。（1）使用最新代码库创建一个新的容器镜像。（2）将镜像推送到镜像仓库中。（3）在运行该镜像的容器宿主机上运行部署脚本。开发环境的ytemd单元会追踪镜像的最新版本，所以只要配置不做修改，那我们只需推送镜像并重新部署即可。类生产环境的服务器（生产环境和预演环境）与开发环境配置方式大体相同，主要区别在于生产环境中的容器镜像都打上了版本标签，而非latet。部署发布镜像到类生产环境容器的流程如下。（1）在仓库中为容器镜像运行发布脚本。该脚本将为Git仓库打上新版本标签，然后使用这个版本号构建并推送镜像。（2）更新每个服务环境变量文件以引用新镜像标签。（3）将新的配置推送到各宿主机中。（4）在运行该镜像的容器宿主机上运行部署脚本。他们通常会批次地将服务从开发环境转移到生产环境（一般是两周一次）。在推送发行版到生产环境时，开发环境中用于该发行版的配置文件会被复制到生产目录中。多数文件可以完全照搬，因为它们是从集群的具体细节（IP地址、宿主机数量等）抽象出来的，不过cluter.ev和ecret.ev文件在各个集群中是不一样的，在发行时也对其进行更新。一般情况下，会一次性推送所有新版本服务。3.6支撑服务PeerSace使用了一组服务来支撑自己的服务。这些服务包括以下两个。●日志聚合：fluetd+kiaa以及docker-ge的组合。docker-ge可根据宿主机中运行的容器创建和重创建一个配置文件。docker-ge为每个运行中的容器生成一个fluetd条目，用于发送日志给kiaa。这个服务运行良好，且易于调试。●监控：Datadog——一个SaaS监控服务。Datadog代理在容器中运行，用于监控各项性能指标、API使用情况和业务事件。Datadog为标签提供了丰富的支持，通过fluetd可以使用多种方式对单一事件进行标记。数据收集起来后（如跨集群的相同服务、所有Docker服务、使用某个发行版的所有API端点等），可以利用丰富的标签对数据进行多种方式的切割。3.7讨论在系统中，所有宿主机和服务的配置都非常明确，开发人员很容易理解系统的配置，并能不受干扰地工作于系统的不同部分上。每位开发人员都可以在任何时候对集成集群进行推送，并且推送到生产环境所需的协调也很少。由于每个集群的配置都保存在Git上，很容易追踪配置的变化，并在出现配置问题时对集群进行排错。因为配置推送的方式，一旦新配置设置妥当，该配置将保持不变。静态配置带来的是极大的稳定性。另外，服务编写的方式，如通过环境变量进行配置、日志写入控制台、无状态等，使得它们之后可原封不动地被Meo或Kuerete这类集群管理工具使用。当然，要得到这些好处是有代价的。一个最明显的缺点是配置有些繁琐、重复并且易出错。我们可以通过大量的自动化的工具来生成这些配置文件。修改全局配置要求重启多个容器。目前是由开发人员来重启正确的容器。在生产环境中，如果推送的修改很多，通常会执行滚动重启，但这并不是一个很好的解决方法。这绝对是一个薄弱环节，但到目前为止，还是可控的。3.8未来PeerSace正在考虑几个系统扩展的方式。其中之一是通过反向代理实现零停机时间部署。这将使得PeerSace有能力对每个服务进行水平扩展。另外一个方向是从集群的更高层级描述中生成所有的配置文件。这种方法能在配置发生改变后计算哪些容器需要重启。在考虑这些未来的方向时，PeerSace也在权衡使用Meo或Kuerete的可能性，因为他们认为，增加部署脚本的任何复杂度势必造成对简单模式的过度拉伸。3.9小结尽管本章讲解了一个极其简单的Docker使用方式，但我们仍希望它能成为“Docker思想”的基石。不论是使用极简方式还是集群管理系统，读者都能利用这种方式在阅读本书其他部分时获益。当然，使用Docker还有很多其他方式，第4章将讲述RelateIQ使用Docker运行了一年多的一个真实的We服务器生产环境。[1]用于隐藏宿主机的真实路径。——译者注第4章示例：We环境我们所知的大多数公司都曾以一个很低的容器和宿主机比例（1~2个容器对应1台宿主机）成功地使用过Docker。也就是说，要在生产环境中成功运行Docker，并不是必须要运行AacheMeo或[1]Kuerate。在本示例中，将对RelateIQ公司使用Docker运行了一年多的一个真实We服务器生产环境做详细的说明。这个环境在运行Uutu的标准亚马逊云服务（AWS）实例上，使用Docker支撑其CRMWe应用。当初使用Docker的原因有三：一是Docker能快速生成和销毁容器，从而为客户提供零停机时间部署；二是因为Docker为不同We版本提供依赖隔离；三是Docker支持即时回滚。图4-1所示为该环境的高层次示图。图4-1相信吗？这个We环境提供了如下功能：稳定的零停机时间部署、回滚、集中式日志、监控及分析JVM的一种方式。所有这些都是通过ah脚本编排Docker镜像获得的。图4-2所示为主机的详细情况。图4-2这台We服务器运行于单台AWS服务器上，并通过Docker运行着4个容器。部分容器被链接在一起，以便与Docker网桥上的其他容器进行通信。它给宿主机公开了多个端口，用于为性能分析提供HTTP服务和JVM监控。它使用了亚马逊ELB负载均衡器（健康检查在其上进行）。所有容器都将它们的日志保存在宿主机上，这样现有的日志方案（SumoLogic）依旧适用，同时有一个简单的ah编排脚本用于部署和设置新版本We服务。为了便于理解很多公司在生产环境中运行Docker时会遇到的问题，我们来看一些具体细节。4.1编排编排归根到底就是做两件事：一是获取已安装Docker的服务器，并且使之准备好运行容器的服务器；二是在服务器上启动并运行容器。4.1.1让服务器上的Docker进入准备运行容器的状态该服务器使用标准的基本UutuAMI（亚马逊机器镜像）在AWS上部署，并通过Chef的标准配置管理系统对宿主机进行设置。其设置过程与当下的多数环境完全相同。服务器启动之后，Chef就会运行并设置h用户、h密钥，然后通过其包安装器安装基础包（如iotat），安装并配置监控代理（本例中是Datadog），集合一些临时磁盘空间用于数据或日志存储，安装并配置日志代理（SumoLogic），安装最新版Docker，最后创建ah设置脚本，并配置一个cro任务来运行它。Chef在服务器上运行之后，宿主机就准备好在其上运行机器所需的任何容器了。Chef还配置了监控和日志软件，用于未来的调试。这个环境可以运行任何类型的容器服务，与当下运行的大多数服务器环境，甚至是物理环境也一般无二。现在，Docker已经安装完毕，宿主机也准备好核心操作工具，下面就可以让宿主机上的容器开始运行试读结束[说明：试读内容隐藏了图片]点击下载...

2022-04-04 生产环境 虚拟机 运行 docker 生产环境虚拟机用动态内存还是固定内存

作者：[美]乔?约翰斯顿（JoeJohto）[西]安东尼?巴彻勒（AtoiBatchelli）出版社：人民邮电出版社格式:AZW3,DOCX,EPUB,MOBI,PDF,TXTDocker生产环境实践指南试读：前言Docker是基础设施的新成员。很少有新兴技术能像它这样，在DevO和基础设施领域中快速风靡起来。在不到两年的时间内，Google、亚马逊、微软、IBM以及几乎所有云供应商都宣布支持运行Docker容器。大量与Docker相关的创业公司在2014年和2015年年初都获得了风险资本的投资。Docker开源技术背后的同名公司——Docker公司，在2015年第一季度的D轮融资中估值为10亿美元左右。大大小小的公司都在转换其应用，使之运行于容器内，以此实现面向服务架构（SOA）和微服务。不论是参加从旧金山到柏林的任何DevO聚会，还是阅读最热门的公司工程博客，都可以看出全世界的运维领导者们如今都在云上运行Docker。毫无疑问，容器已经成为应用程序打包和基础设施自动化的重要组成部分。但有一个棘手的问题，促使本书作者和同僚们创作了另一本Docker图书。本书面向的读者具有中高级DevO和运维背景的读者将从本书获益最多。因而，强烈建议读者应具备在生产环境中运行服务器以及创建和管理容器这两方面的基本经验。很多图书和博客文章已经涵盖了与Docker安装及运行相关的话题，但能把在生产环境中运行Docker时产生的大量甚至是令人挠头的关注点结合在一起的材料则少之又少。不用担心，如果你很喜欢《盗梦空间》（Icetio）这部电影，在云服务器的虚拟机中运行容器会让你感觉很自然。本书将带读者深入理解生产环境中架构的组成部分、关注点，以及如何运行基于Docker的基础设施。谁真的在生产环境中使用Docker换个更深刻的说法，对于在真实生产环境中使用Docker遇到的问题，如何找到解决之道？本书综合了访谈、真实公司端到端的生产环境实例，以及来自DevO杰出专家的参考文献，以此来解答这些问题。虽然本书包含了一些有用的示例，但它并不是一本复制粘贴的“教程式”参考书。相反，本书侧重于生产环境中对前沿技术进行评估、风险抵御及运维所需的实践理论和经验。作为作者，我们希望这本书所包含的内容能够为那些正在评估如何及何时将Docker相关技术引入其DevO栈的团队提供一个可靠的决策指南，这远比代码片段要来得长久。生产环境中运行的Docker为企业提供了多个新的运行和管理服务器端软件的方式。很多现成的用例讲解了如何使用Docker，但很少有公司公开分享过他们的全栈生产环境经验。本书汇集了作者在生产环境中运行Docker的多个实例和一组选定的友好公司分享的使用经验。为什么使用DockerDocker所使用的底层容器技术已经存在了很多年，甚至早于dotCloud这家平台即服务（PaaS）创业公司，即后来我们所熟知的Docker。在dotCloud之前，许多知名的公司（如Heroku和Iro.io）已经在生产环境中运行大型容器集群，以获取额外的超越虚拟机的性能优势。与虚拟机相比，在容器中运行软件赋予了这些公司秒级而非分钟级的实例启动与停止的能力，同时能使用更少的机器运行更多实例。既然这项技术并不新鲜，为什么Docker能获得如此巨大的成功呢？主要是因为它的易用性。Docker创造了一种统一的方式，通过简便的命令行及HTTPAPI工具来打包、运行和维护容器。这种简化降低了将应用程序及其运行时环境打包成一个自包含镜像的入门门槛，使之变得可行且有趣，而不需要类似Chef、Puet及Caitrao之类的配置管理和发布系统。Docker提供了一种统一手段，将应用程序及其运行时环境打包到一个简单的Dockerfile里，这从根本上改变了开发人员与DevO团队之间的交互界面。从而极大简化了开发团队与DevO之间的沟通需求与责任边界。在Docker出现之前，各个公司的开发与运维团队之间经常会爆发史诗般的战争。开发团队想要快速前进，整合最新版的软件及依赖，以及持续部署。运维团队则以保证稳定为己任，他们负责把关可以运行于生产环境中的内容。如果运维团队对新的依赖或需求感到不适，他们通常会站在保守的立场上，要求开发人员使用旧版软件以确保糟糕的代码不会搞垮整台服务器。Docker一下子改变了DevO的决策思维，从“基本上说不”变成了“好的，只要运行在Docker中就可以”，因为糟糕的代码只会让容器崩溃，而不会影响到同一服务器上的其他服务。在这种泛型中，DevO有效地负责为开发人员提供PaaS，而开发人员负责保证其代码能正常运行。如今，很多团队将开发人员加入到PagerDuty中，以监控他们在生产环境中的代码，让DevO和运维人员专注于平台的稳定运行及安全。开发环境与生产环境对大多数团队而言，采用Docker是受开发人员更快的迭代和发布周期需求推动的。这对于开发环境是非常有益的，但对于生产环境，在单台宿主机上运行多个Docker容器可能会导致安全漏洞，这一点我们将在第6章“安全”中讲述。事实上，几乎所有关于在生产环境中运行Docker的话题都是围绕着将开发环境与生产环境区分开的两个关注点进行的：一是编排，二是安全。有些团队试图让开发环境和生产环境尽可能保持一致。这种方法看起来很好，但是限于开发环境这样做所需定制工具的数量又或者说模拟云服务（如AWS）的复杂度，这种方法并不实际。为了简化这本书的范畴，我们将介绍一些部署代码的用例，但判定最佳开发环境设置的实践机会将留给读者。作为基本原则之一，尽量保持生产环境和开发环境的相似性，并使用一个持续集成/持续交付（CI/CD）系统以获取最佳结果。我们所说的“生产环境”对于不同的团队，生产环境意味着不同的东西。在本书中，我们所说的生产环境是指真实客户用于运行代码的环境。这是相对于开发环境、预演环境及测试环境而言的，后者的停机时间不会被客户感知到。在生产环境中，Docker有时是用于接收公共网络流量的容器，有时则是用于处理来自队列负荷的异步的后台作业。不管哪种用途，在生产环境中运行Docker与在其他环境中运行相比，最主要的差异都是需要在其安全性与稳定性上投入较多的注意力。编写本书的动力之一是，与Docker相关的文档和博客文章中缺乏对实际生产环境与其他环境的明确区分。我们认为，80%的Docker博客文章中的建议在尝试在生产环境中运行6个月之后会被放弃（或至少修改）。为什么？因为大多数博客文章中举的都是理想化的例子，使用了最新、最好用的工具，一旦某个极端的情况变成了致命缺陷，这些工具将被遗弃（或延期），被更简单的方法所取代。这是Docker技术生态系统现状的一个反映，而非技术博客的缺陷。总的来说，生产环境很难管理。Docker简化了从开发到生产的工作流程，但同时增加了安全和编排的复杂度（更多关于编排的内容参见第4章）。为了节省时间，下面给出本书的重点综述。所有在生产环境中运行Docker的团队，都会在传统的安全最佳实践上做出一项或多项妥协。如果无法完全信任容器内运行的代码，那么就只得选用容器与虚拟机一对一的拓扑方式。对于很多团队而言，在生产环境中运行Docker的优势远远大于其带来的安全与编排问题。如果遇到工具方面的问题，请等待一到两个月，以便Docker社区对其进行修复，不要浪费时间去修补其他人的工具。保持Docker设置最小化。让一切自动化。最后，对成熟的编排工具（如Meo、Kuerate等）的需求远比想象的要少得多。功能内置与组合工具Docker社区一个常见的口头禅是“电池内置但可移除”，指的是将很多功能捆绑在一起的单体二进制文件，这有别于传统Uix哲学下相对较小、功能单一、管道化的二进制文件。这种单体式的做法是由两个主要因素决定的：（1）使Docker易于开箱即用；（2）Golag缺少动态链接。Docker及多数相关工具都是用Google的Go编程语言编写的，该语言可以简化高并发代码的编写与部署。虽然Go是一门出色的编程语言，但用它来构建的Docker生态系统中也因此迟迟无法实现一个可插拔的架构，在这种架构中可以很容易用替代品对工具进行更换。如果读者有Uix系统背景，最好是编译自己的精简版Docker守护进程，以符合生产环境的需求。如果读者有开发背景，预计到2015[1]年下半年，Docker插件将成为现实。在此期间，估计Docker生态系统中的工具将会出现明显的重叠现象，某些情况下甚至是相互排斥的。换句话说，要让Docker运行于生产环境中，用户的一半工作将是决定哪些工具对自己的技术栈最有意义。与DevO所有事情一样，先从最简单的解决方案入手，然后在必要时增加其复杂性。2015年5月，Docker公司发布了Comoe、Machie及Swarm，与Docker生态系统内的同类工具进行竞争。所有这些工具都是可选的，请根据实际情况对其进行评估，而不要认为Docker公司提供的工具就一定是最佳解决方案。探索Docker生态系统时的另一项关键建议是：评估每个开源工具的资金来源及其商业目标。目前，Docker公司和CoreOS经常发布工具，以争夺关注度和市场份额。一个新工具发布后，最好等上几个月，看看社区的反应，不要因为它看起来很酷就切换到最新、最好用的工具上。哪些东西不要Docker化最后一个关键点是，不要期望能在Docker容器中运行所有东西。Heroku风格的“十二要素”（12factor）应用是最容易Docker化的，因为它们不维护状态。在理想的微服务环境中，容器能在几毫秒内启动、停止而不影响集群的健康或应用程序的状态。类似CluterHQ这样的创业公司正着手实现Docker化数据库和有状态的应用程序，但眼下，由于编排和性能方面的原因，可能需要继续直接在虚拟机或裸机上运行数据库。[2]Docker还不适用于任何需要动态调整CPU和内存要求的应用。允许动态调整的代码已经完成，但尚不清楚何时才能在一般的生产环境中投入使用。目前，若对容器的CPU和内存的限制进行调整，需要停止并重新启动容器。另外，对网络吞吐量有高要求的应用进行最佳优化时不要使用Docker，因为Docker使用itale来完成宿主机IP到容器IP的NAT转换。通过禁用Docker的NAT来提升网络性能是可行的，但这是一个高级的使用场景，很少有团队会在生产环境中这么做。技术审稿人衷心感谢以下技术审稿人提供的早期反馈及细致的评论：MikaTurue、XavierBruhiere和FelixRae。[1]Docker1.7版中正式引入了插件系统。——译者注[2]Docker1.10版中新增的dockerudate命令可实现CPU和内存的动态调整。——译者注第1章入门建立Docker生产环境系统的首要任务，是以一个有助于想象各组件如何相互配合的方式来理解其术语。与其他快速发展的技术生态系统一样，我们可以预见，Docker野心勃勃的市场营销、不完善的文档以及过时的博客文章将造成使用者对各个工具职责理解上的混乱。我们将在本章中定义贯穿全书的术语和概念，而非提供一份统一的Docker百科全书。通常情况下，我们的定义与生态系统中的大体一致，但如果你所阅读的博客文章中使用了不同的术语也不用太过惊讶。在本章中，我们将介绍在生产环境中运行Docker的核心概念以及不涉及具体技术的容器常识。在随后的章节中，我们将讨论真实世界的生产环境用例，并详细说明其组件和供应商信息。1.1术语下面让我们来看一下本书所采用的Docker术语。1.1.1镜像与容器●镜像是指文件系统快照或tar包。●容器是指镜像的运行态。1.1.2容器与虚拟机●虚拟机持有整个操作系统和应用程序的快照。●虚拟机运行着自己的内核。●虚拟机可以运行Liux之外的其他操作系统。●容器只持有应用程序，不过应用程序的概念可以延伸到整个Liux发行版。●容器共享宿主机的内核。●容器只能运行Liux，不过在同一宿主机上运行的每个容器都可包含不同的发行版。1.1.3持续集成/持续交付在应用程序新代码提交或触发其他条件时，系统自动构建新镜像并进行部署。1.1.4宿主机管理设置/配备一台物理服务器或虚拟机以便用于运行Docker容器的过程。1.1.5编排编排（orchetratio，也称编配）这个术语在Docker生态系统中有多种含义。通常情况下，它包括调度和集群管理，不过有时也包括了宿主机管理。在本书中，我们将编排作为一个松散的总称，包括容器调度的过程、集群的管理、容器的链接（发现），以及网络流量路由。或者换句话说，编排是个控制器进程，用于决定在哪里运行容器，以及如何让集群知道可用的服务。1.1.6调度用于决定哪些容器可以以给定的资源约束（如CPU、内存和IO）运行在哪些宿主机上。1.1.7发现容器如何公开服务给集群，以及发现如何查找其他服务并与之通信的过程。举个简单的用例：一个网站应用容器发现如何连接到数据库服务。Docker文档中的发现是指将容器链接在一起，不过在生产级系统中，通常使用的是更复杂的发现机制。1.1.8配置管理配置管理过去常常指的是Docker出现之前的自动化工具，如Chef和Puet。大多数的DevO团队正在转移到Docker上，以消除这类配置管理系统的复杂度。在本书的示例中，配置管理工具只用于配备具有Docker和少量其他东西的宿主机。1.2从开发环境到生产环境本书着重于生产环境或非开发环境中的Docker，这意味着我们不会花太多的篇幅在开发环境中Docker的配置和运行上。但由于所有服务器都在运行代码，如何看待在Docker和非Docker系统中的应用程序代码还是值得简单讨论一下的。与Chef、Puet和Aile这类传统配置系统不同，Docker最好的使用方式是将应用程序代码预先打包成一个Docker镜像。镜像通常包含所有的应用程序代码、运行时的依赖以及系统的需求。而包含数据库凭证和其他敏感信息的配置文件通常在运行时添加，而非内建到镜像中。有些团队会在开发机上手工构建Docker镜像，然后推送到镜像仓库，之后再从仓库中拉取镜像到生产环境宿主机中。这是个很简单的用例。虽然行得通，但从工作流和安全角度考虑并不理想。一个更常见的生产环境示例是，使用持续集成/持续交付系统在应用程序代码或Dockerfile文件发生变更时自动构建新镜像。1.3使用Docker的多种方式过去的几年时间，科技发生了巨大变化，从物理服务器到虚拟服务器，再到拥有PaaS环境的云计算。不论是否采用了全新架构，Docker镜像都可以在当前环境中很容易地被使用。要使用Docker，并不需要立即从单体应用程序迁移到面向服务架构。有很多用例允许在不同层次上集成Docker。Docker常用于以下场景。●使用以镜像为基础的部署方式取代类似Caitrao的代码部署系统。●安全地在同一台服务器中运行遗留应用和新应用。●使用一个工具链循序渐进地迁移到面向服务架构。●管理云端或裸机上的水平扩展性和弹性。●确保从开发环境到预演环境到生产环境跨环境的一致性。●简化开发人员的机器设置和一致性。将应用的后台程序迁移到Docker集群中，同时保持网页服务器和数据库服务器不变是开始使用Docker的常见示例。另一示例是将应用的部分RESTAPI迁移到Docker中运行，前端使用Ngix代理在遗留服务和Docker集群之间路由通信。通过使用此类技术，团队可以渐进式地从单体应用无缝地迁移到面向服务架构。如今的应用程序往往需要几十个第三方库，用于加速功能开发或连接第三方SaaS和数据库服务。每个库都可能产生ug，或是让用户陷入版本依赖的泥沼。再加上库的频繁更改，要在基础设施上完成工作代码的持续部署而不引起失败，压力巨大。Docker可贵的镜像思想使得技术团队在部署工作代码时，不论是单体架构、面向服务或是二者的混合，由于代码及其依赖项捆绑在同一个镜像中，所使用的方式对每次部署都是可测试、可重复、文档化且一致的。一旦一个镜像构建完毕，就可以部署到任意多个运行着Docker守护进程的服务器上。另外一个常见的Docker用例是跨环境部署一个单一容器，其典型的代码路径是从开发环境到预演环境再到生产环境。容器为整个代码路径提供了一个一致的、可测试的环境。作为一个开发人员，Docker模型允许在其个人电脑上调试与生产环境完全一致的代码。开发人员可以很容易地下载、运行和调试有问题的生产环境镜像，且无需事先对本地开发环境进行修改。1.4可预期的情况在生产环境中运行Docker容器困难不小，但还是能实现的。每天都有越来越多公司开始在生产环境中运行Docker。如同所有的基础设施一样，我们建议以小规模入手，然后渐进式地完成迁移。为什么Docker在生产环境如此困难对生产环境有很多要求：安全可靠的部署、健康检查、最小或零停机时间、从失败中恢复的能力（回滚）、一个集中存储日志的方式、一种分析或调试应用的方式，以及一种聚合监控参数的方式。类似Docker这样的新技术虽然使用起来非常有趣，但还需要时间来完善。Docker在可移植性、一致性以及打包具有众多依赖的服务这些方面非常有优势。多数团队会因为以下一个或多个痛点而坚持使用Docker。●一个应用的不同部分使用大量不同的依赖。●支持使用旧依赖的遗留应用程序。●开发团队与DevO之间的工作流问题。本书中我们所采访的团队，有一个共同的警示：切勿尝试在一个组织内让采用Docker这事一蹴而就。即便运维团队已经为采用Docker做好了充分的准备，也请记住，过渡到Docker通常意味着将管理依赖的重任推给了开发人员。虽然很多开发人员都渴求这种自主权，以便加快迭代，但并非每位开发人员都有能力或兴趣将其列入自己的责任范围。为了能有一个良好的Docker工作流，还是需要花些时间来转变企业文化。在第2章中，我们将阐述Docker的技术栈。第2章技术栈生产环境的Docker设置包括了一些基本的架构组件，这些组件对运行容器化的及传统的服务器集群来说是通用的。在很多方面，可以简单地认为构建和运行容器的方式与当前构建和运行虚拟机的方式是一样的，只是使用了一套新的工具和技术。（1）构建并保存镜像快照。（2）将镜像上传到仓库中。（3）下载镜像到某台宿主机中。（4）以容器方式运行镜像。（5）将容器连接到其他服务上。（6）路由流量到容器中。（7）将容器日志发送到指定位置。（8）监控容器。与虚拟机不同的是，容器通过将宿主机（裸机或虚拟机）与应用程序服务隔离，从而提供了更高的灵活性。这为构建和配备流程带来了直接的改善，但由于额外的容器嵌入层，会增加一些开销。典型的Docker技术栈将包括用于解决以下关注点的组件：●构建系统；●镜像仓库；●宿主机管理；●配置管理；●部署；●编排；●日志；●监控。2.1构建系统●如何构建镜像，并将其推送到镜像仓库中？●Dockerfile位于何处？构建Docker镜像通常有以下两种方式。（1）在开发人员电脑上手工构建，然后推送到到仓库中。（2）使用CI/CD系统在代码提交时自动构建。理想的Docker生产环境将使用类似Jeki或Codehi这样的CI/CD（配置集成/持续部署）系统，在代码提交时自动构建镜像。一旦容器构建完毕，它将被发送到镜像仓库中，自动化测试系统就可以从中下载并运行该镜像。2.2镜像仓库●Docker镜像保存在哪里？当前的Docker镜像仓库可靠性比较差，但是每个月都在改善。Docker官方的镜像仓库中心是众所周知的不可靠，需要额外的重试和故障保护措施。多数团队一般会在自己的基础设施上运行私有的镜像仓库，以减少网络传输成本和延迟。2.3宿主机管理●如何配备宿主机？●如何升级宿主机？由于Docker镜像包含了应用及其依赖，宿主机管理系统通常只需要添加新服务器，配置访问权限和防火墙，并安装Docker守护进程即可。类似亚马逊的EC2CotaierService这类服务将消除对传统宿主机管理的依赖。2.4配置管理●如何定义容器的集群？●如何处理宿主机和容器运行时的配置？●如何管理密钥和机密信息？一个基本规则是：尽量避免使用传统的配置管理系统。其增加的复杂性往往会造成故障。Aile、SaltStack、Chef或Puet这类工具仅用于配备带有Docker守护进程的宿主机。尽可能试着摆脱对旧的配置管理系统的依赖，并使用本书所述的发现和集群技术转移到自我配置的容器上。2.5部署●如何将容器放置在宿主机上？镜像部署有以下两种基本方法。（1）推送——部署或编排系统将镜像推送给相关宿主机。（2）拉取——事先或按需从镜像仓库拉取镜像。2.6编排●如何将容器组织成集群？●在哪些服务器上运行容器？●如何调度服务器资源？●如何运行容器？●如何将流量路由给容器？●如何让容器公开和发现服务？“编排=强力胶带”。至少多数情况下可以这么认为。市面上有很多处于早期阶段的全功能容器编排系统，如DockerSwarm、Kuerete、Meo和Fly。但对大多数团队而言，这些系统通常过于强大，增加了在生产环境中出现问题时调试的复杂度。决定使用哪个工具来完成编排常常是设置和运行Docker中最艰难的部分。在第3章中，我们将讲述Peerace所采取的一种构建Docker系统的简约方法。第3章示例：极简环境一说起生产环境中容器的使用，大家的第一反应是那些在同样量级的宿主机上部署成千上万容器的大型公司。但实际上恰恰相反，要发挥容器的作用，并不需要构建如此庞大的系统。小规模的团队反而能从容器中获得最大收益，因为容器使构建和部署服务不仅变得简单，而且可重复、可扩展。本章描述的就是一家名为PeerSace的小规模公司构建系统时采取的一种极简方式。这种极简方式使他们能在短时间内使用有限的资源开辟一个新市场，并自始至终保持着极高的开发速度。PeerSace构建系统时的目标是既要易于开发，又要在生产环境中足够稳定。这两个目标通常是相互矛盾的，因为高速开发引起的大量变化反过来会对系统的构建和配置产生很大影响。任何一个有经验的系统管理员都知道，这样的变化率必然导致不稳定性。Docker看起来非常适合用在刚起步的时候，因为它既对开发人员友好，又支持以敏捷的方式构建和运维系统。Docker简化了开发和系统配置的某些方面，但有时却过于简单化了。在易于开发和稳健运维之间取得平衡不是件容易的事。3.1保持各部分的简单PeerSace实现开发速度和稳定的生产环境这两个目标的方法之一是拥抱简单。这里所说的简单是指系统的每个部分——容器——有且只有一个目标。这个目标就是：相同的过程，如日志收集，在任何地方都以相同的方式完成，而各部分连接的方法也是明确、静态地定义在配置文件中的。在这种简单的系统中，开发人员可以同步地、独立地构建系统的不同部分，并确信构建的容器可组装在一起。另外，在生产环境出现问题时，简单性也让问题的排查与解决变得非常简单。要长期保持系统的简单，需要大量的思考、折中和坚持，但最终这种简单将物有所值。PeerSace的系统由20个零散的微服务组成，其中有部分使用了MogoDB数据库和/或ElaticSearch搜索引擎。该系统设计遵循下列指导原则。（1）倾向无状态服务。这可能是简化PeerSace生产环境时最大的决策：大部分服务都是无状态的。除了用于处理当前进行中的请求的临时信息，无状态服务不需要保持任何需要持久化的数据。无状态服务的优势在于可以非常容易地对他们进行销毁、重启、复制及伸缩，所有这一切都无需考虑任何数据处理方面的逻辑。并且，无状态服务更易于编写。（2）倾向静态配置。所有宿主机和服务的配置都是静态的：一旦给服务器推送一项配置，该配置就会一直生效，直至显式地推送来新配置。与之相对的是那些动态配置的系统，其系统的实际配置是实时生成的，并会根据不同因素（如可用宿主机和即将到达的负载）进行自主修改。尽管动态系统的伸缩性更好，并且具有一些有趣的属性，如在出现某些故障时自动恢复等，但静态配置更易于理解和排错。（3）倾向静态的网络布局。如果在一台宿主机中找到一项服务，除非新配置被确定并提交，否则总能在那台宿主机中找到该服务。（4）区别对待无状态和有状态服务。尽管PeerSace的多数服务是无状态的，他们还是使用MogoDB和ElaticSearch来持久化数据。这两种类型的服务在本质上是非常不同的，应该区别处理。例如，将一个无状态服务从一台宿主机移动到另一台上非常简单，只需要启动新服务，然后停止旧服务即可。但要对一个数据库进行移动，数据也要跟着移动。移动数据可能会花费很长时间，要求在迁移过程中停止服务，或通过设备方法进行在线迁移。在开发领域，通常将无状态服务比做“牲口”，它们没有名字，很容易被代替和伸缩，而将有状态服务比做“宠物”，它们是唯一的、具名的，需要维护，并且难以伸缩。幸运的是，PeerSace正如一个农场一样，其“牲口”数量要远远多于“宠物”。以上这些设计原则是简化PeerSace系统的基础。将有状态服务与无状态服务分离，可以对本质上完全不同的服务进行区别处理（如图3-1所示），因此可以对每一种情况的处理方式进行优化和尽可能地简化。使用静态配置运行无状态服务使得操作系统的流程变得非常简单：多数情况下流程被简化成文件复制和容器重启，完全不需要考虑其他因素，如对第三方系统的依赖。图3-1上述设计准则能否产生一个简单的系统，完全取决于系统操作是否同样简单。3.2保持流程的简单在设计业务流程时，PeerSace基于观察做出了如下假定：在他们的基础设施中离硬件越近的层变更越少，而越接近终端用户的层变更越频繁（如图3-2所示）。图3-2根据这一观察，生产环境中的服务器数量很少变更，通常是由于缩放问题或硬件故障。而这些服务器的配置变更频次可能更高一些，通常是由于性能补丁、系统错误修复或安全问题等原因。在这些服务器上运行的服务数量和类别变更更为频繁。通常是指移动服务、添加新类型服务或对数据进行操作。这个层级上的其他修改可能与要求重新配置或变更第三方服务的新版本部署有关。不过，这类变更仍然不是很常见。在这样的基础设施中，多数的变更与多个服务的新版本推送有关。每天，PeerSace都会执行很多次新版服务的部署。多数情况下，新版本的推送只是简单地将现有版本替换成运行新镜像的新版本。有时也会使用相同镜像，但对配置参数进行变更。PeerSace的流程建立是为了让最频繁的变更最容易也最简单进行，即便这样会造成基础设施更难以变更（实际上并未发生）。3.3系统细节PeerSace运行着3个类生产环境集群：集成环境、预演环境与生产环境。每个集群包含了相同数量的服务，并使用相同的方式进行配置，唯一不同的是它们的原始性能（CPU、内存等）。开发人员同样会在自己的电脑上运行全部或部分集群。每个集群由以下几个部分组成：●几台运行着CetOS7的Docker宿主机，使用ytemd作为系统管理程序；●一台MogoDB服务器或一个复制集合；●一台ElaticSearch服务器或一个集群。MogoDB和/或ElaticSearch服务器可能在某些环境中是Docker化的，而在其他环境中不是Docker化的（如图3-3所示）。它们也会在多个环境中共享。在生产环境中，出于运维和性能的原因，这些数据服务是不做Docker化的。图3-3每个Docker宿主机运行着一个服务的静态集合，所有这些服务都会遵循如下模式进行构建：●所有配置都通过环境变量进行设置，包括其他服务的地址（和端口）；●不将数据写入磁盘；●将日志发送到标准输出（tdout）中；●生命周期由ytemd管理，并定义在一个ytemd单元文件中。利用ytemd所有服务都由ytemd管理。ytemd是一个借鉴了OSXlauchd的服务管理程序，此外，ytemd使用普通数据文件命名单元来定义每个服务的生命周期（如图3-4所示），这与其他使用hell脚本完成这类事务的传统管理程序完全不同。图3-4PeerSace的服务只将Docker进程当作唯一的运行时的依赖。ytemd的依赖管理只用来确保Docker处于运行状态，但不确保其拥有的服务以正确顺序启动。服务构建时要求它们可以以任何顺序启动。所有服务都由以下部分组成（如图3-5所示）：●一个容器镜像；●一个ytemd单元文件；●一个该容器专用的环境变量文件；●一组用于全局配置参数的共享环境变量文件。图3-5所有单元都遵循相同的结构。在服务启动之前，一系列包含环境变量的文件将被加载：EvirometFile=/ur/etc/ervice-locatio.evEvirometFile=/ur/etc/ervice-cofig.evEvirometFile=/ur/etc/cluter.evEvirometFile=/ur/etc/ecret.evEvirometFile=/ur/etc/%.ev这确保了每个服务会加载一系列通用环境文件（ervice-locatio.ev、ervice-cofig.ev、cluter.ev及ecret.ev），外加一个专用于该服务的文件：%.ev，此处的%在运行时将被替换成该单元的全称。例如，一个名为docker-earch的服务单元将被替换成docker-earch.ervice。接下来的条目是确保在启动新容器前旧容器被正确删除的：ExecStartPre=-/i/dockerkill%ExecStartPre=-/i/dockerrm-f%通过使用%，将容器命名为单元的全称。使用变量进行容器命名能让单元文件更通用并且可移植。在docker程序路径之前使用“-”可防止单元在命令失败时中止启动。这里需要忽略潜在的错误，因为如果此前不存在该容器，这些命令将执行失败，而这种情况又是合法的。单元中主要的条目是ExecStart，它将告之ytemd如何启动该容器。这里内容较多，但我们只关注一下其最重要的部分：ExecStart=/i/docker\ru\-"${APP_PORT}:${APP_PORT}"\-e"APP_PORT=${APP_PORT}"\-e"SERVICE_C_HOST=${SERVICE_C_HOST}"\-e"SERVICE_D_HOST=${SERIVCE_D_HOST}"\-e"SERVICE_M_HOST=${SERVICE_M_HOST}"\--add-hotdocker01:${DOCKER01_IP}\--add-hotdocker02:${DOCKER02_IP}\--volume/ur/local/docker-data/%/d:/data/data\--volume/ur/local/docker-data/%/log:/data/log\--ame%\${IMAGE_NAME}:${IMAGE_TAG}（1）使用EvirometFile加载的环境变量来配置容器（如通过-公开的端口）。（2）将集群中的其他宿主机地址添加到容器的/etc/hot文件中（--add-hot）。（3）映射用于日志和数据的数据卷。这主要是作为一个“蜜罐”[1]（hoeyot），以便检查这些目录并确保无人对其进行写入。（4）镜像自身（名称和版本）来自于从/ur/etc/%.ev中加载的环境变量，在本示例中它将映射到/ur/etc/docker-earch.ervice.ev中。最后，是一些定义如何停止容器及其他生命周期要素的条目：ExecSto=-/i/dockerto%Retart=o-failureRetartSec=1TimeoutStartSec=120TimeoutStoSec=303.4集群范围的配置、通用配置及本地配置PeerSace将集群配置分成两种类型文件：环境变量文件和ytemd单元文件。上面已经讲述了单元文件及其加载环境变量文件的方式，接下来看一下环境文件。将环境变量分解到不同文件中的主要原因在于，这些文件在跨集群时是否需要修改以及如何修改，不过也有其他操作层面的原因。●ervice-locatio.ev：集群中所有服务的宿主机名。这个文件在不同集群里通常是一样，不过也有例外。●ervice-cofig.ev：与服务自身相关的配置。如果不同集群运行的是服务的兼容性版本，这个文件应该是一样的。●ecret.ev：密钥信息。因其内容关系，这个文件被处理的方法与其他文件不同，而且在不同集群上也有差异。●cluter.ev：包括了集群间的所有不同之处，如所使用的数据库前缀、是测试还是生产环境、外部地址等。这个文件中最重要的信息是属于该集群的所有宿主机的IP地址。下面是某些示例集群中的文件。这是cluter.ev文件：CLUSTER_ID=alhaCLUSTER_TYPE="tet"DOCKER01_IP=x.x.x.226DOCKER02_IP=x.x.x.144EXTERNAL_ADDRESS=htt://omethigorother.comLOG_STORE_HOST=x.x.x.201LOG_STORE_PORT=9200MONGODB_PREFIX=alhaMONGODB_HOST_01=x.x.x.177MONGODB_HOST_02=x.x.x.299MONGODB_REPLICA_SET_ID=r001这是ervice-locatio.ev文件：SERVICE_A_HOST=docker01SERVICE_B_HOST=docker03CLIENTLOG_HOST=docker02SERIVCE_D_HOST=docker01...SERVICE_Y_HOST=docker03SERVICE_Z_HOST=docker01每个ytemd单元都包含集群中其他宿主机的引用，而这些引用来自于环境变量。包含服务宿主机名的变量会被装配到Docker命令中，以便容器进程使用。这是通过-e参数实现的，如-e"SERVICE_D_HOST=${SERIVCE_D_HOST}"。Docker宿主机的IP地址也同样通过--add-hotdocker01:${DOCKER01_IP}注入到容器中。这样，只需要修改这两个文件并且保持单元文件的完好无损，就可以将容器扩散到不同数量的宿主机中。3.5部署服务容器级别或配置级别的修改通过3个步骤完成：第1步，在配置仓库（Git）上做修改；第2步，将配置文件复制到宿主机的预演区域（h）；第3步，运行宿主机上的一个脚本来逐一部署每个服务，使得配置修改生效。这种方法提供了版本化配置，一次只推送一项相关配置，以及让推送配置生效的一种灵活方式。如果需要针对一组服务进行修改，首先在Git上做修改并提交。然后运行脚本，将这个配置推送到所有宿主机的预演区域。一旦配置被推送过去，在每台宿主机上运行一个脚本来部署或重部署该宿主机上的所有容器集合。这个脚本会对在列的所有服务执行如下命令。（1）将配置文件从预演区域复制到其最终位置：●ytemd单元文件；●共享的配置文件；●当前服务的配置文件；●密钥文件（解密后的）。（2）需要的话下载镜像文件（镜像定义在服务自身的配置文件中）。（3）重载ytemd的配置，以便读取新的单元文件。（4）重启容器对应的ytemd单元。PeerSace具有两个部署工作流，理解这一点有助于阐述其部署流程：一个用于开发环境，另一个用于生产环境，而后者是前者的一个超集。在开发过程中，他们会通过以下步骤将临时构建联署到集成服务器中。（1）使用最新代码库创建一个新的容器镜像。（2）将镜像推送到镜像仓库中。（3）在运行该镜像的容器宿主机上运行部署脚本。开发环境的ytemd单元会追踪镜像的最新版本，所以只要配置不做修改，那我们只需推送镜像并重新部署即可。类生产环境的服务器（生产环境和预演环境）与开发环境配置方式大体相同，主要区别在于生产环境中的容器镜像都打上了版本标签，而非latet。部署发布镜像到类生产环境容器的流程如下。（1）在仓库中为容器镜像运行发布脚本。该脚本将为Git仓库打上新版本标签，然后使用这个版本号构建并推送镜像。（2）更新每个服务环境变量文件以引用新镜像标签。（3）将新的配置推送到各宿主机中。（4）在运行该镜像的容器宿主机上运行部署脚本。他们通常会批次地将服务从开发环境转移到生产环境（一般是两周一次）。在推送发行版到生产环境时，开发环境中用于该发行版的配置文件会被复制到生产目录中。多数文件可以完全照搬，因为它们是从集群的具体细节（IP地址、宿主机数量等）抽象出来的，不过cluter.ev和ecret.ev文件在各个集群中是不一样的，在发行时也对其进行更新。一般情况下，会一次性推送所有新版本服务。3.6支撑服务PeerSace使用了一组服务来支撑自己的服务。这些服务包括以下两个。●日志聚合：fluetd+kiaa以及docker-ge的组合。docker-ge可根据宿主机中运行的容器创建和重创建一个配置文件。docker-ge为每个运行中的容器生成一个fluetd条目，用于发送日志给kiaa。这个服务运行良好，且易于调试。●监控：Datadog——一个SaaS监控服务。Datadog代理在容器中运行，用于监控各项性能指标、API使用情况和业务事件。Datadog为标签提供了丰富的支持，通过fluetd可以使用多种方式对单一事件进行标记。数据收集起来后（如跨集群的相同服务、所有Docker服务、使用某个发行版的所有API端点等），可以利用丰富的标签对数据进行多种方式的切割。3.7讨论在系统中，所有宿主机和服务的配置都非常明确，开发人员很容易理解系统的配置，并能不受干扰地工作于系统的不同部分上。每位开发人员都可以在任何时候对集成集群进行推送，并且推送到生产环境所需的协调也很少。由于每个集群的配置都保存在Git上，很容易追踪配置的变化，并在出现配置问题时对集群进行排错。因为配置推送的方式，一旦新配置设置妥当，该配置将保持不变。静态配置带来的是极大的稳定性。另外，服务编写的方式，如通过环境变量进行配置、日志写入控制台、无状态等，使得它们之后可原封不动地被Meo或Kuerete这类集群管理工具使用。当然，要得到这些好处是有代价的。一个最明显的缺点是配置有些繁琐、重复并且易出错。我们可以通过大量的自动化的工具来生成这些配置文件。修改全局配置要求重启多个容器。目前是由开发人员来重启正确的容器。在生产环境中，如果推送的修改很多，通常会执行滚动重启，但这并不是一个很好的解决方法。这绝对是一个薄弱环节，但到目前为止，还是可控的。3.8未来PeerSace正在考虑几个系统扩展的方式。其中之一是通过反向代理实现零停机时间部署。这将使得PeerSace有能力对每个服务进行水平扩展。另外一个方向是从集群的更高层级描述中生成所有的配置文件。这种方法能在配置发生改变后计算哪些容器需要重启。在考虑这些未来的方向时，PeerSace也在权衡使用Meo或Kuerete的可能性，因为他们认为，增加部署脚本的任何复杂度势必造成对简单模式的过度拉伸。3.9小结尽管本章讲解了一个极其简单的Docker使用方式，但我们仍希望它能成为“Docker思想”的基石。不论是使用极简方式还是集群管理系统，读者都能利用这种方式在阅读本书其他部分时获益。当然，使用Docker还有很多其他方式，第4章将讲述RelateIQ使用Docker运行了一年多的一个真实的We服务器生产环境。[1]用于隐藏宿主机的真实路径。——译者注第4章示例：We环境我们所知的大多数公司都曾以一个很低的容器和宿主机比例（1~2个容器对应1台宿主机）成功地使用过Docker。也就是说，要在生产环境中成功运行Docker，并不是必须要运行AacheMeo或[1]Kuerate。在本示例中，将对RelateIQ公司使用Docker运行了一年多的一个真实We服务器生产环境做详细的说明。这个环境在运行Uutu的标准亚马逊云服务（AWS）实例上，使用Docker支撑其CRMWe应用。当初使用Docker的原因有三：一是Docker能快速生成和销毁容器，从而为客户提供零停机时间部署；二是因为Docker为不同We版本提供依赖隔离；三是Docker支持即时回滚。图4-1所示为该环境的高层次示图。图4-1相信吗？这个We环境提供了如下功能：稳定的零停机时间部署、回滚、集中式日志、监控及分析JVM的一种方式。所有这些都是通过ah脚本编排Docker镜像获得的。图4-2所示为主机的详细情况。图4-2这台We服务器运行于单台AWS服务器上，并通过Docker运行着4个容器。部分容器被链接在一起，以便与Docker网桥上的其他容器进行通信。它给宿主机公开了多个端口，用于为性能分析提供HTTP服务和JVM监控。它使用了亚马逊ELB负载均衡器（健康检查在其上进行）。所有容器都将它们的日志保存在宿主机上，这样现有的日志方案（SumoLogic）依旧适用，同时有一个简单的ah编排脚本用于部署和设置新版本We服务。为了便于理解很多公司在生产环境中运行Docker时会遇到的问题，我们来看一些具体细节。4.1编排编排归根到底就是做两件事：一是获取已安装Docker的服务器，并且使之准备好运行容器的服务器；二是在服务器上启动并运行容器。4.1.1让服务器上的Docker进入准备运行容器的状态该服务器使用标准的基本UutuAMI（亚马逊机器镜像）在AWS上部署，并通过Chef的标准配置管理系统对宿主机进行设置。其设置过程与当下的多数环境完全相同。服务器启动之后，Chef就会运行并设置h用户、h密钥，然后通过其包安装器安装基础包（如iotat），安装并配置监控代理（本例中是Datadog），集合一些临时磁盘空间用于数据或日志存储，安装并配置日志代理（SumoLogic），安装最新版Docker，最后创建ah设置脚本，并配置一个cro任务来运行它。Chef在服务器上运行之后，宿主机就准备好在其上运行机器所需的任何容器了。Chef还配置了监控和日志软件，用于未来的调试。这个环境可以运行任何类型的容器服务，与当下运行的大多数服务器环境，甚至是物理环境也一般无二。现在，Docker已经安装完毕，宿主机也准备好核心操作工具，下面就可以让宿主机上的容器开始运行试读结束[说明：试读内容隐藏了图片]点击下载...

2022-04-02 生产环境 虚拟机 运行 docker 生产环境虚拟机用动态内存还是固定内存